Revisões técnicas formais

ENGENHARIA DE SOFTWARE:

INTRODUÇÃO

APOSTILA DA DISCIPLINA ENGENHARIA DE SOFTWARE I

INSTITUTO DE CIÊNCIA DA COMPUTAÇÃO - UFF

Prof. Teresa Cristina de Aguiar

________________________________________________________

ÍNDICE:

I.INTRODUÇÃO 3

I.1 HISTÓRICO DA ENGENHARIA DE SOFTWARE [Ghezzi-91] 3

I.2 CONCEITO DE ENGENHARIA DE SOFTWARE [Pressman-95] 3

I.3 DIFICULDADES E MITOS DA ENGENHARIA DE SOFTWARE [Pressman-95] 4

I.4 SISTEMAS 5

I.5 QUALIDADE 6

I.6 FASES DA ENGENHARIA DE SOFTWARE 7

II. FASE DE DEFINIÇÃO [Pressman-95] 9

II.1 PLANEJAMENTO DO PROJETO 9

II.2 ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS 10

II.2.1 ATIVIDADES FUNDAMENTAIS, O ANALISTA DE SISTEMA E CAUSAS DE PROBLEMAS [PRESSMAN-95] 10

II.2.2 COMO OBTER REQUISITOS [Yourdon-90] [Pressman-95] 11

II.2.3 REVISÃO DA ESPECIFICAÇÃO 13

III. FASE DE DESENVOLVIMENTO 14

III.1 ASPECTOS FUNDAMENTAIS DE PROJETO 14

III.2 PROJETO DE SISTEMA [Rumbaugh-94] 16

III.3 PROJETO DE ARQUITETURA 17

III.4 PROJETO DE DADOS 22

III.5 PROJETO DE INTERFACE 23

IV. FASE DE VERIFICAÇÃO, LIBERAÇÃO E MANUTENÇÃO 26

IV.1 ESTRATÉGIAS DE TESTE DE SOFTWARE 26

IV.2 MANUTENÇÃO 28

V. PARADIGMAS DA ENGENHARIA DE SOFTWARE 31

VI. CASE 35

Esta apostila tem como objetivo descrever as principais atividades da Engenharia de Software, ciclos de vida e CASE, enfatizando as atividades de Análise e Projeto. Com relação a Análise e Projeto, é apresentada nesta apostila a abordagem estruturada. O estudo da etapa de Análise deve ser acompanhado também através da apostila Análise Essencial.

1. INTRODUÇÃO

Nesta primeira seção a Engenharia de Software é introduzida, apresentando-se um histórico, os conceitos de Engenharia de Software e de sistemas, dificuldades da área, fatores de qualidade desejáveis em sistemas de software e por fim as principais atividades da Engenharia de Software.

I.1 HISTÓRICO DA ENGENHARIA DE SOFTWARE [Ghezzi-91]

Primeiros tempos da computação:

• 
  Os problemas consistiam em como organizar uma seqüência de instruções de forma que o computador pudesse fazer algo útil
  
• 
  Os problemas eram bem entendidos
  
• 
  O programa era escrito por alguém tentando resolver um problema de seu próprio interesse
  

Final da década de 50:

• 
  Linguagens de alto nível foram inventadas
  
• 
  Poucos projetos grandes de software foram realizados
  

Meados dos anos 60 até a década de 70:

• 
  Já estavam sendo comercializados sistemas de grande porte
  
• 
  Surgem as software-houses
  
• 
  Através das experiências que vinham sendo realizadas chegaram à conclusão que desenvolver sistemas grandes era bem diferente de desenvolver pequenos sistemas
  
• 
  O esforço de manutenção dos sistemas já desenvolvidos começou a absorver recursos em índices alarmantes
  
• 
  “Crise do software”: Um termo inventado nesta época
  

Crise do Software

• 
  Várias soluções foram propostas e experimentadas
  
• 
  Consenso final: O problema da construção de software deve ser encarado da mesma forma que outras engenharias que constróem sistemas complexos, como pontes, navios, refinarias, etc. O sistema de software deve ser visto como um produto complexo e sua construção como um trabalho de engenharia.
  

E assim a Engenharia de Software nasceu.

I.2 CONCEITO DE ENGENHARIA DE SOFTWARE [Pressman-95]

“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, em 1969.

A Engenharia de Software abrange um conjunto de 3 elementos fundamentais: Métodos, Ferramentas e Procedimentos.
Métodos: proporcionam os detalhes de como fazer para construir o software. Há métodos para planejamento, análise de requisitos, projeto de dados, arquitetura de programa, testes, etc. Os métodos utilizam notações gráficas ou textuais e podem introduzir um conjunto de critérios para melhoria da qualidade.
Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos métodos.
Procedimentos: definem a seqüência em que os métodos serão aplicados, quais os produtos a serem entregues, que controles serão adotados para ajudar a assegurar a qualidade e a coordenar as mudanças e quais marcos serão adotados para possibilitar aos gerentes na avaliação do progresso.

I.3 DIFICULDADES E MITOS DA ENGENHARIA DE SOFTWARE [Pressman-95]

Dificuldades:

• 
  As estimativas de prazos e de custos freqüentemente são imprecisas
  
• 
  A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços
  
• 
  A qualidade de software às vezes é menor do que a esperada. Somente há pouco tempo começou a ser entendida a importância dos testes de software sistemáticos e tecnicamente completos. Somente a pouco começaram a surgir conceitos quantitativos sólidos de confiabilidade e garantia da qualidade de software.
  
• 
  O software existente pode ser muito difícil de se manter.
  
• 
  A insatisfação do cliente com os sistema concluído ocorre muito freqüentemente. A comunicação cliente-desenvolvedor é freqüentemente muito fraca.
  

• 
  Não tem havido dedicação em coletar dados sobre o processo de desenvolvimento. Com poucos dados históricos como guia, as estimativas têm sido realizadas sem base, com resultados ruins. Sem nenhuma indicação sólida de produtividade, não se pode avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões.
  

Mitos:
Há frases que ainda são ditas como verdades indiscutíveis. Pressman relaciona algumas delas, apresentando o que considera a realidade atual.
Mitos administrativos:

• 
  Já temos um manual repleto de padrões e procedimentos para a construção de software. Isso não oferecerá a meu pessoal tudo o que eles precisam saber ?
  

Realidade: É muito comum que mesmo que exista um padrão ele não seja utilizado. Muitas vezes não se sabe de sua existência, ou está incompleto, ou não reflete as modernas práticas de desenvolvimento de software.

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

Realidade: Para desenvolver software de qualidade é preciso mais do que o último modelo de um computador.

• 
  Se estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso.
  

Realidade: Para se acrescentar pessoas a uma equipe deve-se planejar bem porque as pessoas que estavam trabalhando podem vir a gastar tempo ensinando os recém-chegados, o que reduz o tempo dedicado ao desenvolvimento.
Mitos do cliente:

• 
  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.

• 
  Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível.
  

Realidade: Os requisitos de software modificam ao longo do tempo, mas o impacto da mudança varia de acordo com o tempo em que ela é introduzida. Se uma séria atenção for dada à definição inicial, os primeiros pedidos de mudança podem ser acomodados facilmente. O cliente pode rever as exigências e recomendar modificações sem causar grande impacto sobre os custos. Porém, quanto mais tarde for exigida uma mudança maior o impacto sobre os custos.
Mitos do profissional:

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

Realidade: A idéia é que quanto mais cedo se começa a escrever o código mais tempo demora para que se consiga terminá-lo.

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

Realidade: As revisões de software são filtros da qualidade e têm sido consideradas mais eficientes do que a realização de testes para a descoberta de certas classes de defeitos de software.

• 
  A única coisa a ser entregue em um projeto bem-sucedido é o programa funcionando.
  

Realidade: O programa funcionando é somente uma parte de uma configuração de software que inclui o plano do projeto, a especificação de requisitos, a especificação de testes, dentre outros.