AulaEngSW01

Engenharia de Software I

Prof. Lucio Kamiji lucio.kamiji@unifil.br

Importância do Software

• 1950 a 1980: desenvolvimento de hardware que reduzisse o custo de processamento.

• 1980 a 1990: avanços da microeletrônica resultou em maior poder de processamento e custo cada vez mais baixo.

• A partir de 1990: melhorar a qualidade de soluções (softwares) baseadas no

O papel evolutivo do Software

1950 1960 1970 1980 1990 2000 Os primeiros anos • Orientação batch • Distribuição limitada • Software customizado A segunda era • Multiusuário • Tempo Real • Banco de Dados • Produto de software A terceira era • Sistemas distribuídos • “Inteligência” embutida • Hardware de baixo custo • Impacto de consumo

A quarta era

• Sistemas de desk-top poderosos • Tecnologia orientadas a objeto • Sistemas especialistas

• Redes neurais artificiais • Computação paralela

Características do Software

Tempo T a x a d e F a lh a s

Curva de falhas (banheira) para o hardware

“Mortalidade infantil”

Curva de Falhas Ideal do SW

Tempo T a x a d a s F a lh a s Contínua na mesma taxa até a obsolecência

Curvas de Falhas Real do SW

Tempo T a x a d e F a lh a s Mudança

Software

• Componentes do Software (reusabilidade)

– Duas formas:

• Componentes não executáveis • Componentes executáveis

• Aplicações do Software

– Software básico (S.O., compiladores, utilitários, drivers) – Software de Tempo Real (controla o mundo real)

– Software Comercial (estoque, CR, CP, CT)

– Software Científico e de Engenharia (CAD, teste de fadiga) – Software Embutido (residente na memória)

– Software de Computador Pessoal (planilhas, processador de texto) – Software de Inteligência Artificial (baseados em conhecimento)

Problemas

01) Estimativas de prazo e de custo

freqüentemente são imprecisas (falham); 02) Produtividade das pessoas da área de

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

03) Qualidade de software às vezes é menos que adequada.

Dificuldades:

1) Pouco tempo dedicado para coletar dados sobre o processo de desenvolvimento de software (poucos históricos, chutes, etc...);

2) Insatisfação do cliente com o sistema “concluído” ocorre freqüentemente (requisitos pobres,

comunicação fraca);

3) Qualidade de software é freqüentemente suspeita (testes de software, ferramentas, etc...); e

Causas:

01) Os problemas foram causados pelo próprio caráter do software e pelas falhas das pessoas que detinham a

responsabilidade pelo desenvolvimento; 02) Desafio intelectual do desenvolvimento; 03) Baixa comunicação entre todas as pessoas

envolvidas no projeto;

04) Pouco treinamento formal em novas técnicas para o desenvolvimento; e

Mitos do Software

• Mitos Administrativos: os responsáveis pelo

desenvolvimento encontram-se sobre pressão para manter o orçamento, evitar que os prazos saiam de controle e melhorarem a qualidade.

• Mitos do Cliente: Os clientes acham que os responsáveis pelo desenvolvimento devem saber (conhecimento) de tudo sobre as demais áreas.

• Mitos do Profissional: a programação era vista como uma forma de arte e velhas maneiras e atitudes dificilmente morrem (mais de 4 décadas).

Mitos Administrativos

• Mito: Já temos um manual de padrões

e procedimentos para a construção de software.

• Realidade: O manual pode existir, mas

será que é usado? Os profissionais têm conhecimento de sua existência?

Mitos Administrativos

• Mito: Meu pessoal tem ferramentas de

desenvolvimento de última geração; afinal de contas compramos o mais novos

computadores.

• Realidade: É preciso muito mais que novos

computadores para desenvolver software de qualidade. Ferramentas adequadas de CASE são mais importantes que os computadores.

Mitos Administrativos

• Mito: Se estamos atrasados nos prazos

podemos adicionar mais programadores e tirar o atraso (conceito hordas de mongóis).

• Realidade: “... acrescentar mais pessoas em

um projeto de software atrasado torna-o ainda mais atrasado” [Brooks, F., The

Mitos do Cliente

• Mito: Uma declaração geral dos

objetivos é suficiente para se começar a escrever programas - podemos

preencher os detalhes mais tarde.

• Realidade: Uma definição inicial ruim é

a principal causa de fracasso dos esforços de desenvolvimento de software

Mitos do Cliente

• Mito: Os requisitos de projeto

modificam-se continuamente, mas as mudanças podem ser facilmente

acomodadas, porque o software é flexível.

• Realidade: O impacto da mudança

varia de acordo com o tempo em que é introduzida.

O Impacto da Mudança

Custo da Mudança

Definição Desenvolvimento Manutenção

1x

1.5 -6x

60 -100x

Alto Custo de Requisitos Errados

A regra 1-10-100 100 25 10 5 2.5 .5 - 1 Estágio Tempo de Requisitos Projeto Codificação Teste Aceitação do Teste Manutenção

Custo relativo para corrigir erros:

Quando introduzido x quando reparado

“Todos juntos, os resultados mostram que existe uma

relação de 200:1 no % do custo entre erros encontrados no estágio de requisitos e no de manutenção do ciclo de vida do software.”

% custo médio é 14:1 Grady 1989

Mitos do Profissional

• Mito: Assim que escrevermos o

programa e o colocarmos em

funcionamento nosso trabalho estará completo.

• Realidade: Existe indicação de que 50

a 70% de todo o esforço gasto num programa serão despendidos depois que ele for entregue ao cliente.

Mitos do Profissional

• Mito: Enquanto não tiver o programa

“funcionando”, eu não terei realmente nenhuma maneira de avaliar sua

qualidade.

• Realidade: A revisão técnica formal

tem sido considerado mais eficiente do que a realização de testes.

Mitos do Profissional

• Mito: A única coisa a ser entregue em

um projeto bem-sucedido é o programa funcionando.

• Realidade: Os programas funcionando

é apenas uma parte de uma

Paradigmas da Engenharia de

Software

• Engenharia de Software:

– É o estabelecimento e uso de sólidos princípios de

engenharia para que se possa obter economicamente um software que seja confiável e que funcione

eficientemente em máquinas reais. (Fritz Bauer)

– É abordagem sistemática, disciplinada e possível de ser medida para o desenvolvimento, operação e

Ciclo de Vida Clássico

Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção

Críticas ao Ciclo de Vida

Clássico

• Projetos raramente seguem o fluxo seqüencial

proposto. Sempre existe iterações e traz problemas na aplicação.

• Dificilmente o usuário define claramente todos os requisitos.

• O usuário deve ter paciência, porque uma versão do sistema estará pronto num ponto tardio do

cronograma. Qualquer erro crasso pode ser desastroso.

Prototipação

Coleta e refinamento dos requisitos Projeto rápido Construção do protótipo Avaliação do protótipo pelo cliente Refinamento do protótipo Engenharia do produto Início Fim

Prototipação

• É um processo que capacita o

desenvolvedor a criar um modelo do software que será implementado.

– Pode assumir 3 formas:

• protótipo em papel ou modelo baseado no PC que retrata a interação homem-máquina;

• protótipo de trabalho que implementa algum subconjunto de funcionalidades; e

• programa existente que implementa parte ou toda funcionalidade.

Modelo Espiral

Planejamento Análise dos Riscos

Avaliação do Cliente Engenharia

Análise dos riscos baseada nos requisitos iniciais

Análise dos riscos baseada na reação do cliente Decisão de Prosseguir ou não Na direção de um sistema concluido

Coleta inicial dos Requisitos e Planejamento do Projeto

Planejamento baseado nos comentários do cliente

Avaliação do cliente

Protótipo de Software inicial

Protótipo de nível seguinte

Modelo Espiral

• Planejamento:

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

• Análise dos riscos:

– análise de alternativas e identificação/resolução dos riscos

• Engenharia:

– desenvolvimento do produto no ”nível seguinte”

• Avaliação feita pelo cliente:

Técnicas da 4a. Geração

Coleta de requisitos Estratégia de Projeto Implement. usando 4GL Teste

A Natureza Mutante do

Desenvolvimento do Software

1970 1980 1990 2000

Métodos convencionais

Demanda

global Aplicações de _{“técnicas de} quarta geração” D em an da d e so ft w ar e

Combinando Paradigmas

Obtenção preliminar dos requisitos

Análise de requisitos Projeto Realização de testes 4GT (técnicas de quarta geração) Codificação Prototipação Enésima iteração Modelo espiral 4GT (técnicas de quarta geração) 4GT (técnicas de quarta geração) Enésima iteração Sistema Operacional Manutenção

Visão Genérica da Engenharia de

Software (3 fases)

• Definição (o quê?):

– Análise do Sistema

– Planejamento do Projeto de Software – Análise de Requisitos • Desenvolvimento (como?): – Projeto de Software – Codificação – Testes do Software • Manutenção: – Correção – Adaptação – Melhoria funcional

Fase de Definição do Processo de

Software

Focaliza "

Focaliza "o que_{o que}" ser" seráá desenvolvidodesenvolvido

• que informação será processada

• que funcionalidade e desempenho são desejados • que comportamento pode ser esperado do sistema • que interfaces serão estabelecidas

• que restrições de projeto existem

• que critérios de validação são exigidos para definir um sistema bem sucedido

Fase de Definição do Processo de

Software

Focaliza "

Focaliza "o queo que" seráá desenvolvido" ser desenvolvido

• que informação será processada

• que funcionalidade e desempenho são desejados • que comportamento pode ser esperado do sistema • que interfaces serão estabelecidas

• que restrições de projeto existem

• que critérios de validação são exigidos para definir um sistema bem sucedido

Análise de Sistemas

Planejamento do Projeto de Software Análise de Requisitos

Fase de Desenvolvimento do

Processo de Software

Focaliza "

Focaliza "comocomo" o software ser" o software seráá desenvolvidodesenvolvido

• como os dados serão estruturados

• como uma funcionalidade será implementada com uma arquitetura de software

• como os detalhes de procedimentos serão implementados • como as interfaces serão caracterizadas

• como o projeto será traduzido numa linguagem de programação

Fase de Desenvolvimento do

Processo de Software

Focaliza "como" o software ser

Focaliza "como" o software seráá desenvolvidodesenvolvido

• como os dados serão estruturados

• como a funcionalidade será implementada com uma arquitetura de software

• como os detalhes procedimentais serão implementados • como as interfaces serão caracterizadas

• como o projeto será traduzido em uma linguagem de programação

• como os testes serão efetuados

Projeto do Software Codificação

Fase de Manutenção do Processo

de Software

Focaliza as "

Focaliza as "mudanmudanççasas" que ocorrerão depois " que ocorrerão depois

que o software for liberado para uso

que o software for liberado para uso

operacional

operacional

• A fase de manutenção reaplica os passos das fases de definição e desenvolvimento, mas faz isso no contexto de um software existente

Fase de Manutenção do Processo

de Software

Focaliza as "

Focaliza as "mudanmudanççasas" que ocorrerão depois " que ocorrerão depois que o software for liberado para uso

que o software for liberado para uso operacional

operacional

• A fase de manutenção reaplica os passos das fases de definição e desenvolvimento, mas faz isso no contexto de um software existente

Correção Adaptações

Bibliografia

PRESSMAN, Roger S. ENGENHARIA DE SOFTWARE. São Paulo: Makron Books, 1995. (páginas 1 a 49).

As Melhores Práticas da

Engenharia de Software

• Desenvolvimento Iterativo • Gerência de Requisitos

• Uso da Arquitetura de Componentes • Modelo Visual (UML)

• Verificação Contínua da Qualidade • Gerência da Mudança

R.U.P. Implementa as

Melhores Práticas

• O RUP é um processo de negócio genérico para engenharia de software orientado a

objeto.

• Ele descreve uma família de processo de engenharia de software tendo em comum a estrutura e arquitetura de processo.

Desenvolvimento Iterativo

Produz um Executável

Requisitos Análise e Projetos Implementação Teste Implantação Planejamento Planejamento Inicial Avaliação Gerenciamento do Ambiente Cada Iteração resulta num release executável

Estrutura do processo – fases do ciclo de

vida

O RUP tem quatro fases:

• Inception – define o escopo de projeto

• Elaboration – plano do projeto, especifica funcionalidades, arquitetura básica

• Construction – construção do produto

• Transition – transição do produto dentro da comunidade do usuário final

Gerenciamento de Requisitos: Visão Geral

Procedimentos

de Teste Projeto User Docs Problema Espaço da Solução Espaço do Problema Neces-sidades Características Use Cases e Requisitos de Software Produto a Produto a ser ser constru construíídodo R ast rea bil_id ad_e