Análise e Desenho de

Software
Conferencia nº 3: Ciclo de vida clássico:
Codificação, provas de software e
manutenção
 Codificação
Esta etapa tem como finalidade traduzir
em forma legível para o computador o
desenho desenvolvido na etapa anterior.
Esta actividade implica a criação de
programas informáticos aplicando as
estruturas de programação de algum
paradigma e utilizando uma linguagem
apropriada para a programação
 O estilo de codificação deve produzir um
código compreensível ou seja:
• O código deve documentar-se com a
eleição de identificadores (variáveis e
etiquetas) que sejam significativos (ex:
dist é pior que distancia como
identificador)
I. Se deve incorporar comentários no inicio
de cada módulo que indiquem:
- A função do módulo
- Uma descrição da sua interface e os
argumentos que tenha.
- Descrição das estruturas de dados mais
significativas que o módulo utiliza.
- A história de cada módulo (autor,
data de criação e modificação)
- Comentários descritivos no corpo do
módulo, para descrever as funções de
processamento)
II. Os dados se devem declarar
naqueles lugares que proporcionem um
acesso rápido na hora de identificá-
los dentro de uma sentença. É normal
declará-los no principio de cada
módulo com uma ordem determinada.
Por exemplo:
• Declaração de tipo simples (ex: int,
float, char,…)
• Declaração de tipo estruturado (ex:
ponteiros, array, struct,…)
• Declaração de arquivos (ex: file,
open,…),
• etc
III. AS sentenças devem ser simples e
fáceis de seguir.
- Se devem evitar comparações
condicionais complicadas,
- Evitar comparações com condições
negativas
- deve-se usar parêntesis para dar
mais legibilidade as sentenças.
- Usar várias linhas para sentenças
demasiado longas.
IV. As entradas/saídas devem ser
cuidadosamente codificadas, já que
originam muitas vezes erros difíceis
de localizar.
É importante:
- manter um formato de entrada
simples
- validar todos os dados de entrada
- Usar indicativos de fim de entrada de
dados em vez de especificar o
numero de dados a ler.
- Etc.
 Provas
do
Software
• As provas do software são um
elemento crítico para a garantia da
qualidade do software e representam
uma revisão final das especificações,
do desenho e da codificação. Não é
raro que estas provas representem
40% do custo total do projecto.
• Em cada fase do ciclo de
desenvolvimento do software
projectam-se um conjunto de provas
que permitem constatar que o
software desenvolvido satisfaz as
especificações desta fase.
• Durante a fase de “Análise do
Sistema” se especificam as provas do
sistema, que têm como objectivo
comprovar que todo o sistema (parte
manual, software desenvolvido, bases
de dados existentes, etc) funciona
correctamente.
• Durante a fase de “Análise dos
requisitos do software” especificam-
se as provas de validação, que
consistem em comprovar que o
software desenvolvido satisfaz todas
as expectativas razoáveis do cliente,
quer dizer, satisfaz todos os
requisitos funcionais, de
Comportamento e de rendimento
especificados durante a fase de
análise.
• Durante a fase de “Desenho”
especificam-se as provas de
integração, que consistem em
comprovar que o programa criou-se
correctamente.
O objectivo é pegar cada módulo já
provado e integra-lo no software
que se está a desenvolver e
comprovar que globalmente funciona
correctamente.
• Ao terminar a codificação de cada
módulo realiza-se a prova de unidade
que consiste em comprovar que o
módulo funciona correctamente, quer
dizer, que todos os caminhos de
controlo importantes executam-se de
acordo com o especificado.
• As provas de unidade são “caixa
Branca” e “Caixa Negra” e tratam
fundamentalmente:

- A interface do módulo, analisando

que a informação entra e sai
correctamente do módulo.
- As estruturas de dados locais, já que
são uma fonte potencial de erros.
- Os valores limites estabelecidos para
cada módulo.
- Os caminhos independentes das
estruturas de controlo, assegurando
que todas as sentenças do módulo
executam-se pelo menos uma vez.

- O tratamento dos erros,

comprovando que se executam e são
os adequados.
 Formas de realizar as
provas
• Provas de caixa negra
Se levam a cabo sobre a interface do
software e pretendem demonstrar
que o software funciona
adequadamente; quer dizer, as
entradas se aceitam de forma
adequada e que se produz uma saída
correcta. Estas provas não têm em
conta a estrutura lógica interna do
software.
• Provas de caixa branca
Se baseiam num minucioso exame dos
detalhes procedimentais. Comprovam-
se os caminhos lógicos do software
com o fim de examinar troços
específicos do programa (ciclos,
sentenças, bifurcações, etc.)
Nota: o processo de codificação do
software numa linguagem informática
e a sua validação , mediante provas de
jogo de ensaio ou de técnicas
especificas, conhece-se como
implementação do sofware.
Manutenção
• O software produzido na fase de
desenvolvimento deve ser
acompanhado com uma manutenção
permanente já que sofrerá mudanças
depois de ser entregue ao cliente.
Estas mudanças ocorrerão devido a:
a) Erros encontrados (manutenção
correctiva)
b) Mudanças no entorno as quais o
software deve adaptar-se, por
exemplo a incorporação de um novo
sistema operativo (manutenção
adaptativa)
C) Que o cliente requeira ampliações
funcionais ou deseje incrementar o
seu rendimento (manutenção de
aperfeiçoamento)
• A actividade de manutenção é a mais
importante na Organização. O seu
custo passou dos 35% - 40% do
orçamento da empresa nos anos 70 a
uns 70% actualmente.
 Formula de L. Belady
• Reflecte o esforço da empresa na
manutenção:

M = p + k *e ( c− f )
• Onde:
M – custo total da manutenção
p – Custo resultante de tarefas
produtivas netas de manutenção (para
a análise, desenho e implementação)
k – constante empírica
C- medida da complexidade do
software (devida a um mau desenho
e/ou uma má documentação)
f – Medida do grau de familiaridade
com o software desenvolvido
• Este modelo indica:
- Que o custo de manutenção pode
aumentar exponencialmente se se
utiliza uma má engenharia de
desenvolvimento do software e as
pessoas que o desenvolveram não
estão disponíveis para o manter
- Dentro da manutenção existe uma
etapa prévia ao processo rotineiro de
manutenção que é a transferência de
tecnologia
Transferência de tecnologia

\É o processo em que os
desenvolvedores do sistema
transferem os seus conhecimentos
sobre o mesmo para os usuários
Os usuários necessitam de um
meticuloso treino onde lhes é
explicado o uso do próprio sistema o
conteúdo da documentação que se
transfere com o mesmo. A
documentação que normalmente se
transfere com o sistema é:
• Especificações do sistema.
• Especificações do software.
• Desenho
• Código fonte.
• Plano de provas
• Manual do cliente.