Engenharia de Software I

ENGENHARIA DE SOFTWARE:
ENGENHARIA DE SOFTWARE I
INSTITUTO DE CINCIA DA COMPUTAO - UFF
Prof. Teresa Cristina de Aguiar
________________________________________________________
_____________________________________________________________________________________
NDICE:
I. INTRODUO..........................................................................................................................................
I.1 HISTRICO DA ENGENHARIA DE SOFTWARE 3
I.2 CONCEITO DE ENGENHARIA DE SOFTWARE 4
I.3 DIFICULDADES E MITOS DA ENGENHARIA DE SOFTWARE 4
I.4 SISTEMAS 6
I.5 QUALIDADE 6
I.6 FASES DA ENGENHARIA DE SOFTWARE 7
II. FASE DE DEFINIO.................................................................................................................................
II.1 PLANEJAMENTO DO PROJETO 9
II.2 ANLISE E ESPECIFICAO DE REQUISITOS10
II.2.1 ATIVIDADES FUNDAMENTAIS, O ANALISTA DE SISTEMA E CAUSAS DE
PROBLEMAS...........................................................................................................................................
II.2.2 COMO OBTER REQUISITOS...............................................................................................
II.2.3 REVISO DA ESPECIFICAO...........................................................................................
III. FASE DE DESENVOLVIMENTO...........................................................................................................
III.1 ASPECTOS FUNDAMENTAIS DE PROJETO 15
III.2 PROJETO DE SISTEMA 18
III.3 PROJETO DE ARQUITETURA 19
III.4 PROJETO DE DADOS 24
III.5 PROJETO DE INTERFACE 26
IV. FASE DE VERIFICAO, LIBERAO E MANUTENO...........................................................
IV.1 ESTRATGIAS DE TESTE DE SOFTWARE 30
IV.2 MANUTENO 33
V. PARADIGMAS DA ENGENHARIA DE SOFTWARE............................................................................
VI. CASE..........................................................................................................................................................
_____________________________________________________________________________________
Apostila - Engenharia de Software: Introduo
_____________________________________________________________________________________
Esta apostila tem como objetivo descrever as principais atividades da Engenharia

de Software, ciclos de vida e CASE, enfatizando as atividades de Anlise e Projeto. Com
relao a Anlise e Projeto, apresentada nesta apostila a abordagem estruturada. O
estudo da etapa de Anlise deve ser acompanhado tambm atravs da apostila Anlise
Essencial.
I. INTRODUO
Nesta primeira seo a Engenharia de Software introduzida, apresentando-se um

histrico, os conceitos de Engenharia de Software e de sistemas, dificuldades da rea,
fatores de qualidade desejveis em sistemas de software e por fim as principais atividades
da Engenharia de Software.
I.1 HISTRICO DA ENGENHARIA DE SOFTWARE [Ghezzi-91]
Primeiros tempos da computao:

Os problemas consistiam em como organizar uma seqncia de instrues de forma que
o computador pudesse fazer algo til
Os problemas eram bem entendidos
O programa era escrito por algum tentando resolver um problema de seu prprio
interesse
Final da dcada de 50:

Linguagens de alto nvel foram inventadas
Poucos projetos grandes de software foram realizados
Meados dos anos 60 at a dcada de 70:

J estavam sendo comercializados sistemas de grande porte
Surgem as software-houses
Atravs das experincias que vinham sendo realizadas chegaram concluso que
desenvolver sistemas grandes era bem diferente de desenvolver pequenos sistemas
O esforo de manuteno dos sistemas j desenvolvidos comeou a absorver recursos
em ndices alarmantes
Crise do software: Um termo inventado nesta poca
Crise do Software
Vrias solues foram propostas e experimentadas
Consenso final: O problema da construo de software deve ser encarado da mesma
forma que outras engenharias que constrem sistemas complexos, como pontes, navios,
refinarias, etc. O sistema de software deve ser visto como um produto complexo e sua
construo 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 slidos princpios de engenharia para que se possa obter

economicamente um software que seja confivel e que funcione eficientemente em
mquinas reais. Fritz Bauer, em 1969.
A Engenharia de Software abrange um conjunto de 3 elementos fundamentais:

Mtodos, Ferramentas e Procedimentos.
Mtodos: proporcionam os detalhes de como fazer para construir o software. H mtodos

para planejamento, anlise de requisitos, projeto de dados, arquitetura de programa,
testes, etc. Os mtodos utilizam notaes grficas ou textuais e podem introduzir um
conjunto de critrios para melhoria da qualidade.
Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos mtodos.
Procedimentos: definem a seqncia em que os mtodos sero aplicados, quais os produtos

a serem entregues, que controles sero adotados para ajudar a assegurar a qualidade e a
coordenar as mudanas e quais marcos sero adotados para possibilitar aos gerentes na
avaliao do progresso.
I.3 DIFICULDADES E MITOS DA ENGENHARIA DE SOFTWARE [Pressman-95]
Dificuldades:
As estimativas de prazos e de custos freqentemente so imprecisas

A produtividade das pessoas da rea de software no tem acompanhado a demanda por
seus servios
A qualidade de software s vezes menor do que a esperada. Somente h pouco tempo
comeou a ser entendida a importncia dos testes de software sistemticos e
tecnicamente completos. Somente a pouco comearam a surgir conceitos quantitativos
slidos de confiabilidade e garantia da qualidade de software.
O software existente pode ser muito difcil de se manter.
A insatisfao do cliente com os sistema concludo ocorre muito freqentemente. A
comunicao cliente-desenvolvedor freqentemente muito fraca.
No tem havido dedicao em coletar dados sobre o processo de desenvolvimento. Com
poucos dados histricos como guia, as estimativas tm sido realizadas sem base, com
resultados ruins. Sem nenhuma indicao slida de produtividade, no se pode avaliar
com preciso a eficcia de novas ferramentas, mtodos ou padres.
Mitos:
H frases que ainda so ditas como verdades indiscutveis. Pressman relaciona algumas
delas, apresentando o que considera a realidade atual.
_____________________________________________________________________________________
_____________________________________________________________________________________
Mitos administrativos:
J temos um manual repleto de padres e procedimentos para a construo de

software. Isso no oferecer a meu pessoal tudo o que eles precisam saber ?
Realidade: muito comum que mesmo que exista um padro ele no seja utilizado.
Muitas vezes no se sabe de sua existncia, ou est incompleto, ou no reflete as
modernas prticas de desenvolvimento de software.
Meu pessoal tem ferramentas de desenvolvimento de software de ltima gerao;
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 recm-
chegados, o que reduz o tempo dedicado ao desenvolvimento.
Mitos do cliente:
Uma declarao geral dos objetivos suficiente para se comear a escrever programas
podemos preencher os detalhes mais tarde.
Realidade: Uma definio inicial ruim a principal causa de fracasso dos esforos de
desenvolvimento de software.
Os requisitos de projeto modificam-se continuamente, mas as mudanas podem ser
facilmente acomodadas, porque o software flexvel .
Realidade: Os requisitos de software modificam ao longo do tempo, mas o impacto da
mudana varia de acordo com o tempo em que ela introduzida. Se uma sria ateno
for dada definio inicial, os primeiros pedidos de mudana podem ser acomodados
facilmente. O cliente pode rever as exigncias e recomendar modificaes sem causar
grande impacto sobre os custos. Porm, quanto mais tarde for exigida uma mudana
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 idia que quanto mais cedo se comea a escrever o cdigo mais tempo
demora para que se consiga termin-lo.
Enquanto no tiver o programa funcionando, eu no terei realmente nenhuma maneira
de avaliar a sua qualidade
Realidade: As revises de software so filtros da qualidade e tm sido consideradas
mais eficientes do que a realizao 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 configurao de
software que inclui o plano do projeto, a especificao de requisitos, a especificao de
testes, dentre outros.
_____________________________________________________________________________________
_____________________________________________________________________________________
I.4 SISTEMAS
Sistema: Um conjunto ou disposio de coisas relacionadas a ponto de formar uma unidade

ou um todo orgnico.
Sistema baseado em computador: Um conjunto ou disposio de elementos organizados

para executar certo mtodo, procedimento ou controle ao processar informaes.
Elementos de um sistema baseado em computador:

Software
Hardware
Pessoas
Banco de Dados
Documentao
Procedimentos
Sistemas de Informao baseados em computador: [Melo-97]

No incio da computao dados eram armazenados no prprio programa j que no
havia dispositivos de acesso direto. Desta forma os procedimentos relacionados a gerncia
de dados misturavam-se com os de interao com o usurio e com os relacionados ao
prprio negcio.
Ao surgirem os discos magnticos os dados passaram a ser armazenados em local
distinto, organizando-se em arquivos. Com esta organizao qualquer alterao na estrutura
dos arquivos implica na alterao das funes de gerncia de dados, presentes em cada
programa.
A desejada independncia de dados surgiu com os sistemas de gerncia de banco de
dados (SGBD), que renem todas as funes necessrias localizao e manipulao dos
dados de interesse dos sistemas de informao.
I.5 QUALIDADE
Em [Pressman-95] apresentada a seguinte lista de fatores que afetam a qualidade

do software proposta por McCall e seus colegas:
Fatores relacionados operao do software:
Correo: O quanto o software satisfaz as especificaes e atende aos objetivos do

cliente. (Ele faz o que quero ?)
Confiabilidade: O quanto espera-se que o software realize suas funes com preciso,
sem erros. (Ele se comporta com preciso o tempo todo ?)
Eficincia: O total de recursos computacionais e cdigo requerido por um software
para realizar suas funes. (Ele rodar em meu hardware to bem quanto possvel ?)
Integridade: O quanto o acesso ao software ou dados, por pessoas no autorizadas,
pode ser controlado. (Ele seguro ?)
Facilidade de uso: O esforo requerido para aprender, operar, preparar entradas e
interpretar as sadas do software. (Ele foi projetado para o usurio ?)
_____________________________________________________________________________________
_____________________________________________________________________________________
Fatores relacionados reviso do software:
Facilidade de realizar manutenes: O esforo requerido para localizar e corrigir um

erro num software. (Posso consert-lo ?)
Flexibilidade: O esforo requerido para modificar um software. (Posso mud-lo ?)
Facilidade de realizar testes: O esforo requerido para testar um software de forma
a assegurar que ele realiza as funes desejadas. (Posso test-lo ?)
Fatores relacionados evoluo do software:
Portabilidade: O esforo requerido para transferir um software de um hardware para

outro ou de um ambiente para outro. (Serei capaz de us-lo em outra mquina ?)
Facilidade de reuso: O quanto um software (ou partes dele) pode se reusado em
outras aplicaes. (Serei capaz de reutilizar parte do software ?)
Interoperabilidade: O quanto um software tem facilidade em cooperar com outros.
Exemplo de cooperao: um processador de texto que incorpora uma figura gerada por
um pacote grfico. (Serei capaz de compor uma interface com outro sistema ?)
difcil e em certos casos impossvel medir com uma nica mtrica os fatores
descritos. definido ento um conjunto de mtricas relacionadas a cada fator. As mtricas
podem estar na forma de uma lista de verificao (checklist), que usada para graduar
atributos especficos do software. Por exemplo, no caso do fator facilidade de realizar
manutenes, poderiam ser utilizadas as seguintes mtricas:
Conciso: a caracterstica de um programa realizar as funes desejadas
implementadas com o mnimo possvel de cdigo.
Consistncia: uso de tcnicas de projeto e documentao uniformes ao longo do projeto
de desenvolvimento de software.
Instrumentao: o quanto o programa monitora sua prpria operao e identifica erros
que venham a ocorrer.
Modularidade: o quanto h independnica funcional dos componentes do programa.
Independncia funcional conseguida desenvolvendo-se mdulos com um s propsito e
evitando-se interaes excessivas com outros mdulos. Pode ser medida usando-se
como critrios a coeso e o acoplamento.
Autodocumentao: o quanto o cdigo fonte apresenta documentao significante.
Simplicidade: o quanto o programa pode ser entendido sem dificuldades.
I.6 FASES DA ENGENHARIA DE SOFTWARE
A figura apresentada na pgina seguinte, de [Pressman-95], representa as fases

genricas da Engenharia de Software. Este processo divide-se em trs etapas principais
que so detalhadas ao longo dessa apostila:
(a) Definio (descrita na seo II)

(b) Desenvolvimento (descrita na seo III)
(c) Verificao, liberao e manuteno (descrita na seo IV)
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
II. FASE DE DEFINIO [Pressman-95]
Definio a primeira etapa do processo de desenvolvimento e manuteno. Inclui o

planejamento do projeto, a reviso do Plano de Projeto, a anlise e especificao de
requisitos e a reviso dos produtos gerados nesta ltima atividade. A seguir so abordados
esses assuntos.
II.1 PLANEJAMENTO DO PROJETO
Grandes sistemas de software devem ser vistos como produtos complexos e a sua
construo como um trabalho de engenharia. A abordagem de engenharia requer
gerenciamento, organizao, ferramentas, teorias, metodologias e tcnicas.
O planejamento do projeto de desenvolvimento de software uma das atividades

de administrao de projetos, envolvendo a especificao dos objetivos do projeto e como
alcan-los alm da definio de que recursos sero necessrios, como e quando obt-los.
Ao iniciar o planejamento do projeto importante que sejam definidos e

documentados:
os objetivos e restries do projeto: o projeto necessita de um definio clara
de seus objetivos, capaz de guiar os participantes do processo em suas decises.
comum que muito tempo seja desperdiado discutindo-se alternativas que so
conhecidas claramente pelo gerente do projeto, mas que no foram documentadas e
nem disseminadas adequadamente.
os riscos do projeto: os riscos esto presentes em todos os projetos e por essa
razo devem ser analisados e controlados.
os recursos necessrios de pessoal, hardware e software para o
desenvolvimento, alm de outros recursos especiais que sejam necessrios .
o cronograma do projeto: deve-se criar uma rede que represente cada etapa do
desenvolvimento, sua dependncia de outras tarefas e durao.
como os profissionais estaro organizados.
o custo do projeto.
Estas informaes devem fazer parte do Plano do Projeto de Software, um

documento, ou conjunto de documentos, que daro apoio ao gerente em sua atividade de
planejamento.
O Plano do Projeto de Software deve ser um documento simples e seu nvel de

detalhamento depender do pblico ao qual destinado e da necessidade de um grau maior
ou menor de formalismo. Ao longo do projeto pode haver a necessidade de se modificar o
Plano devido ao contnuo controle que deve ser exercido pelo gerente de projetos.
O plano dever ser revisado. A seguir so apresentados alguns dos itens a serem
considerados numa lista de verificao (ver Revises Tcnicas Formais):
O escopo do software definido e delimitado com clareza ?
A terminologia utilizada clara ?
Os recursos so adequados ?
_____________________________________________________________________________________
_____________________________________________________________________________________
Os recursos esto disponveis ?

Os riscos mais importantes foram definidos ?
Um plano de gerenciamento de riscos est em andamento ?
As tarefas para realizao do projeto so definidas e colocadas numa seqncia
adequada?
O paralelismo entre tarefas razovel, em funo dos recursos disponveis ?
A base para a estimativa de custos razovel ? Foram utilizados mtodos ?
Os oramentos e prazos estimados so realistas ?
Foram utilizados dados histricos para a realizao de estimativas ?
O cronograma consistente ?
O controle realizado pelo gerente de projetos de software para administrar os

recursos do projeto, enfrentar problemas e dirigir o pessoal de projeto. Se tudo estiver
caminhando bem (isto , se o projeto estiver no prazo e dentro do oramento, as revises
indicarem progresso real e os marcos estiverem sendo atingidos), fcil realizar o
controle. Mas quando ocorrerem problemas, o gerente de projetos dever exercer o
controle para san-los o mais rapidamente possvel. Depois que o problema tiver sido
diagnosticado, recursos adicionais podem ser concentrados na rea do problema, o pessoal
pode ser reorganizado ou pode ser necessrio redefinir as atividades do projeto.
[Pressman-95]
O controle do projeto pode ser realizado de vrias maneiras:

Realizando-se reunies peridicas sobre a situao do projeto, nas quais cada membro
da equipe dever relatar o progresso e os problemas.
Avaliando-se os resultados de todas as revises levadas a efeito ao longo do progresso
de engenharia de software.
Verificando-se se os marcos do projeto foram atingidos at a data programada.
Comparando-se a data de incio real com a data de incio planejada para cada tarefa do
projeto.
Reunindo-se informalmente com profissionais para obter suas avaliaes subjetivas do
progresso at o momento e dos problemas que podem j estar percebendo para o
futuro.
II.2 ANLISE E ESPECIFICAO DE REQUISITOS
II.2.1 ATIVIDADES FUNDAMENTAIS, O ANALISTA DE SISTEMA E CAUSAS DE

PROBLEMAS [PRESSMAN-95]
A seguir so apresentadas as atividades consideradas fundamentais na anlise e

especificao de requisitos: reconhecimento do problema, avaliao e sntese, modelagem e
especificao.
a) Reconhecimento do problema:
O analista estuda a Especificao do Sistema (caso exista) e o Plano do Projeto.
O analista estabelece contato com todos aqueles que esto relacionados ao projeto.
A meta do analista o reconhecimento dos elementos problemticos bsicos,
conforme percebidos pelo usurio/cliente.
_____________________________________________________________________________________
_____________________________________________________________________________________
b) Avaliao e sntese:
O analista deve:
Avaliar o fluxo e o contedo da informao
Definir e elaborar todas as funes do software
Entender o comportamento do software no contexto dos eventos que afetam o
sistema
Estabelecer as caractersticas de interface com o sistema
Descobrir restries de projeto.
Depois de avaliar os problemas atuais e as informaes desejadas (entrada e sada),
o analista comea a sintetizar uma ou mais solues.
c) Modelagem:
Durante a atividade de avaliao e sntese o analista cria modelos do sistema num
esforo para compreender melhor o fluxo de dados e de controle, o
processamento funcional, etc. O modelo serve como um fundamento para o projeto
de software e como base para a criao de sua especificao.
O foco principal desta atividade deve ser o que e no como.
d) Especificao:
As tcnicas de anlise podem levar a uma especificao em papel ou baseada em
computador que contenha descries em linguagem natural e grfica dos requisitos de
software.
H vrias propostas de formatos de especificaes, como os propostos pelo
National Bureau of Standards, o IEEE e o Departamento de Defesa Americano.
Alguns dos itens que deveriam constar de uma especificao so:
Objetivos e restries do projeto

Descrio dos dados
Descrio das funes
Descrio comportamental
Exigncias de desempenho
Descrio da interface
Critrios de validao (Descrio dos testes a serem realizados para validar a
funo, o desempenho e as restries especificadas).
Bibliografia
Apndices
Para facilitar a gerao de especificaes so utilizados mtodos. Atualmente os
mtodos mais utilizados com este objetivo so os baseados na Anlise Estruturada e
na Anlise Orientada a Objetos [Pressman-95] . Na apostila Anlise Essencial deste
curso apresentado um mtodo baseado na Anlise Estruturada e no prximo curso
(Engenharia de Software II) apresentada a abordagem orientada a objetos.
O analista de sistemas tem como funo definir os elementos para um sistema

especfico baseado em computador. Para optar por uma soluo o analista faz
consideraes dos seguintes tipos:
Consideraes de projeto (prazo, custo, etc)

_____________________________________________________________________________________
_____________________________________________________________________________________
Consideraes de negcios
Anlise tcnica
Avaliao da manufatura
Questes humanas
Interfaces ambientais
Consideraes jurdicas
Algumas das causas apontadas pelas dificuldades nesta rea so:
Dificuldade de comunicao
Tendncia a se realizar esta atividade o mais rpido possvel, iniciando-se logo a
codificao
Uso de tcnicas e ferramentas inadequadas, resultando em especificaes
imprecisas
II.2.2 COMO OBTER REQUISITOS [Yourdon-90] [Pressman-95]
Podemos obter requisitos atravs de:

Entrevistas
FAST ( Facilitaded Application Specification Techniques) Ex: JAD (Joint
Application Development)
Questionrios
Observao de aplicaes semelhantes
Coleta de formulrios, relatrios, manuais, imagens de telas, listagens de
programas, etc, que contenham dados sobre o sistema
Pesquisa em livros e relatrios de pesquisa
Entrevistas:
Diretrizes:
Desenvolva um plano geral de entrevistas
Obtenha prvia autorizao para entrevistar as pessoas
Planeje cada contato com o entrevistado
Certifique-se que a pessoa selecionada conhece o assunto da entrevista
Colete, antecipadamente, tantos dados quanto possvel
Prepare as perguntas antecipadamente
Utilize ferramentas automatizadas quando adequado. Por exemplo para a
prototipagem.
Obtenha informaes dos vrios participantes do projeto.
Utilize um estilo adequado:

Relacionamentos pede-se ao entrevistado que explique o relacionamento
entre o que est em discusso e as demais partes do sistema
Pontos de vista alternativos pede-se ao entrevistado que descreva o ponto de
vista de outros em relao ao item que est sendo discutido
Detalhamento
Confirmao
Dependncias
_____________________________________________________________________________________
_____________________________________________________________________________________
Problemas que podem surgir:

Pessoas que no conseguem descrever seu conhecimento
Pessoas que no desejam passar seu conhecimento para outros
Pessoas que do palpites sobre assuntos dos quais no tm conhecimento
Confuso entre o que pertence ao sistema e o que externo a ele
Dificuldade de se chegar a um consenso quando vrias pessoas so entrevistadas
separadamente
FAST (Facilitaded Application Specification Techniques)
Muitas abordagens de FAST tm sido propostas com as seguintes diretrizes bsicas:
No encontro inicial entre o desenvolvedor e o cliente surgem perguntas e

respostas bsicas que ajudam a estabelecer o escopo do problema e a percepo
de uma soluo.
Aps esses encontros iniciais, o desenvolvedor e o cliente escrevem uma requisio
de produto de uma ou duas pginas.
Um lugar, uma data e um horrio para a FAST so escolhidos e um moderador
designado.
Integrantes das organizaes tanto do desenvolvedor como do cliente so
convidados a participar.
A requisio do produto distribuda a todos os participantes antes da data do
encontro.
A cada participante solicitada uma descrio de sua viso do sistema.
Regras para a preparao e participao so estabelecidas
Uma agenda que seja formal o bastante para cobrir todos os pontos importantes,
mas informal o suficiente para encorajar o livre fluxo de idias sugerida.
Um encontro realizado num local neutro e conta com a participao tanto de
desenvolvedores como de clientes.
Um mecanismo de apresentao (planilha, cartazes, etc) usado.
A meta identificar o problema, propor elementos de soluo, negociar diferentes
abordagens e especificar um conjunto preliminar de requisitos de soluo num
clima que facilite a realizao da atividade.
Exemplo de FAST: JAD (Joint Application Development)
Mtodo desenvolvido e utilizado na IBM

Criado na dcada de 70 no Canad e introduzido no Brasil em 85, com adaptaes.
Rene os vrios participantes do projeto num encontro longo e previamente
planejado.
Encontros do JAD:
Reunio Inicial: A sesso de design planejada
Reunio de Reviso: revisto o que foi combinado na reunio inicial.
Sesso de Design: A atividade planejada realizada.
_____________________________________________________________________________________
_____________________________________________________________________________________
II.2.3 REVISO DA ESPECIFICAO
A reviso conduzida tanto pelo desenvolvedor como pelo cliente para garantir que:
O escopo do projeto foi corretamente delineado
As funes, o desempenho e as interfaces foram adequadamente definidas
A anlise do ambiente e dos riscos de desenvolvimento justificam o sistema
O desenvolvedor do sistema e o cliente tm a mesma percepo dos objetivos do
sistema
Podem ser realizadas desde revises informais at as revises tcnicas formais.

Podemos realizar revises informais, atravs por exemplo de uma solicitao para que um
colega de trabalho verifique rapidamente o que acha de algum aspecto de um dos produtos
do processo de desenvolvimento. H, no entanto, revises mais formais que requerem mais
tempo e dedicao para serem realizadas, como o walkthrough e a inspeo.
As revises tcnicas formais (RTFs) atuam como filtros, purificando os produtos ao

longo do processo de desenvolvimento.
Atravs das RTFs pode-se verificar se o que est sendo revisto atende a
requisitos j estabelecidos e a padres previamente definidos.
H dois tipos de revises:

Ad hoc: Todos os revisores utilizam tcnicas no sistemticas e a eles so atribudas
as mesmas responsabilidades.
Com uso de checklist: utilizada uma lista de verificao com o objetivo de sugerir
formas dos revisores identificarem falhas.
As RTFs so realizadas atravs de reunies. Independente do tipo da reviso toda

reunio deve seguir os seguintes preceitos:
Deve envolver entre 3 e 5 pessoas.
Deve haver uma preparao antes da reunio. No entanto, no se deve requerer de cada
pessoa um trabalho de mais de 2 horas.
A durao da reunio no deve ultrapassar duas horas.
Antes da reunio de reviso so realizadas as seguintes atividades:

A pessoa que est desenvolvendo o produto deve comunicar ao lder do projeto que est
no momento de submeter o produto reviso.
O lder do projeto entra em contato com o lder de reviso que avalia o produto quanto
a sua facilidade de leitura, gera cpias e distribui para os revisores.
O lder de reviso estabelece uma agenda para a reunio.
Durante a reunio importante que sejam observados os seguintes aspectos:

Devem estar presentes o lder da reviso, os revisores e aquele que desenvolveu o
produto.
A reunio comea com uma explicao da agenda e aquele que desenvolveu o produto
explica o material, enquanto os revisores interrompem quando necessrio para dar suas
sugestes e criticar.
Cada erro ou problema detectado anotado por um dos revisores que assume o papel
de redator.
_____________________________________________________________________________________
_____________________________________________________________________________________
Ao fim da reunio o grupo presente deve decidir se:

Aceitam o produto sem modificaes.
Rejeitam o produto devido a erros srios (quando esses erros tiverem sido corrigidos
outra reunio dever ser realizada).
Aceitam o produto provisoriamente. Os erros que foram encontrados devero ser
corrigidos mas no necessria uma nova reunio.
Algumas das vantagens das RTFs so as seguintes:

So teis para o treinamento, j que permitem aos novos profissionais um contato com
o que est sendo usado na Empresa.
Possibilitam que vrias pessoas tenham contato com partes do sistema, disseminando
informaes.
A reviso realizada nas fases iniciais do desenvolvimento possibilita que determinados
erros sejam logo descobertos.
III. FASE DE DESENVOLVIMENTO
A Fase de Desenvolvimento a etapa do processo de desenvolvimento e

manuteno, descrito na seo I.6, que inclui o Projeto de Sistema, o Projeto de
Arquitetura, o Projeto de Dados, o Projeto Procedimental, o Projeto da Interface e a
Codificao, alm das revises necessrias aos produtos gerados em cada etapa.
Nesta apostila sero abordados os aspectos fundamentais de projeto e os projetos

de sistema, de arquitetura e de dados.
III.1 ASPECTOS FUNDAMENTAIS DE PROJETO
Abstrao
Refinamento
Modularidade
Arquitetura de software
Hierarquia de controle
Estrutura de dados
Procedimento de software
Ocultao de informao
a) Abstrao
... a noo psicolgica de abstrao permite que uma pessoa se concentre num
problema com certo nvel de generalizao, sem levar em considerao detalhes
irrelevantes de menor nvel; o uso de abstrao tambm permite que se trabalhe com
conceitos e termos que so familiares ao ambiente do problema sem que seja preciso
transform-los em uma estrutura no-familiar... Wasserman
Durante o desenvolvimento o software definido em vrios nveis de abstrao.
Durante a anlise e especificao de requisitos definido em termos que so familiares aos
usurios. Conforme se caminha no processo de desenvolvimento o nvel de abstrao vai
ficando cada vez mais relacionado a aspectos de implementao.
_____________________________________________________________________________________
_____________________________________________________________________________________
Abstrao procedimental:
Uma sequncia de instrues designadas que tem uma funo especfica e limitada.
Considerando um programa, a descrio de seus objetivos seria uma primeira
abstrao procedimental. Depois a elaborao das tarefas a serem realizadas seria uma
segunda abstrao. A terceira seria o pseudo-cdigo e por fim a quarta o cdigo-fonte na
linguagem escolhida.
Abstrao de dados:
uma coleo designada de dados que descreve um objeto de dados. Por exemplo,
cheque de pagamento um objeto de dados que representa vrias informaes diferentes:
nome da pessoa a quem se paga, quantia bruta paga, imposto retido, imposto de renda,
contribuio para a previdncia, etc..
Contudo podemos nos referir a todos os dados ao declararmos o nome da abstrao
de dados.
A abstrao de dados possibilita que o projetista represente um objeto de dados
em nveis variveis de detalhe e, o que mais importante, que ele especifique um objeto de
dados no contexto das operaes que podem ser aplicadas a ele.
Quando usamos o tipo real para representar nmeros reais estamos usando uma
abstrao de dados, sem saber muito sobre a representao deste tipo no computador.
(Esta representao varia de um para outro computador). Para usar um objeto de dados no
programa cliente deve-se declarar a varivel como daquele tipo.
Logo que uma abstrao de dados definida, um conjunto de operaes que podem
ser aplicadas a ela tambm definido.
Vrias linguagens tm mecanismos que permitem a criao de tipos abstratos de
dados (combinao de um tipo de dado com seus operadores), que usado como um padro
ou estrutura de dados genrica a partir da qual outras estruturas de dados podem ser
representadas por uma instncia.
b) Refinamento
O refinamento um processo de elaborao.
Em cada passo (do refinamento), uma ou mais instrues do programa dado so
decompostas em instrues mais detalhadas. Essa sucessiva decomposio ou refinamento
das especificaes termina quando todas as instrues so expressas em termos de
qualquer linguagem de programao ou computador subjacente... medida que as tarefas
so refinadas, tambm os dados podem ter de ser refinados, decompostos ou estruturados,
e natural refinar-se os programas e as especificaes de dados paralelamente.
Cada passo de refinamento implica algumas decises de projeto... Wirth
c) Modularidade
Um software constitudo de um nico mdulo no pode ser facilmente entendido e
modificado. O software deve ser dividido em componentes separadamente nomeados e
endereveis denominados mdulos.
Um sistema pode ser projetado modularmente, mesmo que sua implementao deva
ser monoltica. H situaes, como software de tempo real, em que gastos com memria e
velocidade introduzidos por subprogramas so inaceitveis. Em tais situaes, o software
pode e deve ser projetado, tendo a modularidade como filosofia. Apesar do cdigo-fonte
_____________________________________________________________________________________
_____________________________________________________________________________________
no parecer modular primeira vista, o programa apresentar os benefcios de um sistema

modular.
d) Arquitetura de software
O problema a ser resolvido pelo software, definido na anlise de requisitos,
derivado numa arquitetura de software a partir de um processo de diviso em parties. A
arquitetura de software trata da estrutura hierrquica de mdulos e da estrutura de
dados.
Um mtodo de projeto pode ser usado para se derivar a estrutura, mas uma vez que
cada um se baseia em diferentes conceitos fundamentais de bom projeto, cada mtodo
poder levar a uma estrutura diferente para o mesmo conjunto de requisitos. Apesar de
no se poder afirmar qual a melhor, h caractersticas de uma estrutura que podem ser
examinadas para se determinar a qualidade da soluo.
e) Hierarquia de controle
Tambm chamada de estrutura de programa, representa a organizao de mdulos
de programa. Uma notao que utilizada o diagrama em rvore. Termos que so
utilizados so:
Profundidade: indicao do nmero de nveis de controle
Largura: indicao do espao de controle global.
Fan-out: medida do nmero de mdulos que so diretamente controlados por outro
mdulo (ou seja, o nmero de mdulos que chamam o mdulo sendo analisado)
Fan-in: indica quantos mdulos controlam (chamam) diretamente determinado mdulo.
Subordinado: um mdulo controlado por outro subordinado ao controlador
A hierarquia de controle representa duas caractersticas diferentes da arquitetura

de software: a visibilidade e a conectividade.
Visibilidade: indica o conjunto de componentes de programa que pode ser invocado ou
usado como dados por determinado componente.
Conectividade: indica o conjunto de componentes que diretamente invocado ou usado
como dados por determinado componente.
De forma a representar a hierarquia de controle pode ser utilizado o Diagrama de
Estrutura apresentado na seo V.4 desta apostila.
f) Estrutura de dados
Representa o relacionamento lgico entre elementos de dados individuais.
Determina a organizao, mtodos de acesso, grau de associatividade e alternativas de
processamento de informaes.
A organizao e a complexidade de uma estrutura de dados depender da
habilidade do projetista. H no entanto certas estruturas de dados clssicas que formam
outras estruturas mais sofisticadas.
Item escalar: a mais simples de todas as estruturas de dados. Representa um nico
elemento de informao que pode ser endereado por um identificador. Seu tamanho e
formato podem variar de acordo com a linguagem de programao.
Vetor sequencial: itens escalares organizados como uma lista ou como um grupo
contguo. Quando o vetor sequencial ampliado para duas, trs e mais dimenses, um
espao n-dimensional criado.
Lista: organiza itens de dados, arrays, de modo que possibilita que eles sejam
processados como uma lista. Cada n contm a organizao de dados apropriada (por
_____________________________________________________________________________________
_____________________________________________________________________________________
exemplo, um vetor) e um ou mais ponteiros que indicam o endereo de armazenamento

do prximo n da lista. Ns podem ser adicionados a qualquer ponto da lista ao se
redefinir os ponteiros que acomodam a nova entrada da lista.
Etc...
g) Procedimento de software
Focaliza os detalhes de processamento de cada mdulo individualmente. Deve
oferecer uma especificao precisa do processamento.
h) Ocultao de informao
De acordo com este princpio os mdulos devem ser especificados e projetados de
tal forma que as informaes (procedimento e dados) contidas num mdulo sejam
inacessveis a outros mdulos que no tenham necessidade de tais informaes. Assim,
quando houver necessidade de modificaes, os erros que forem introduzidos contra nossa
vontade tm menos chances de se propagar para outras localizaes dentro do software.
III.2 PROJETO DE SISTEMA [Rumbaugh-94]
durante o projeto de Sistemas que o sistema organizado em sub-sistemas e so

tomadas decises estratgicas de alto nvel.
Decises a serem tomadas:
a) Organizar o sistema em subsistemas
Cada um dos principais componentes de um sistema denominado subsistema. Cada

subsistema compartilha propriedades comuns como funcionalidade similar ou execuo no
mesmo tipo de hardware. Cada subsistema tem uma bem definida interface com o restante
do sistema.
O relacionamento entre dois subsistemas pode ser do tipo cliente-servidor ou do tipo
homogneo.
Cliente-servidor: o cliente convoca o servidor, que executa algum servio e fornece um
resultado.
Homogneo: cada um dos subsistemas pode chamar os outros. A comunicao de um
sistema com outro no necessariamente seguida por uma resposta imediata.
b) Alocar subsistemas a processadores e tarefas
Cada subsistema concorrente deve ser alocado por exemplo a uma unidade de hardware
ou a um processador de emprego geral.
Esta deciso depender de se necessitar de um desempenho melhor do que aquele dado
por uma nica CPU ou tambm pelo fato de certas tarefas serem necessrias em
localizaes fsicas especficas.
Deve-se escolher a organizao e a forma de conexes entre as unidades fsicas.
c) Escolher uma abordagem para o gerenciamento de depsitos de dados

Arquivos, SGDBs ?
d) Determinar mecanismos para controlar acesso a recursos globais

_____________________________________________________________________________________
_____________________________________________________________________________________
Exemplos de recursos globais so unidades fsicas, como processadores, unidades de

fita e satlites de comunicao.
e) Escolher uma implementao de controle de software
Exemplos de controle:
Sistemas seqenciais baseados em procedimentos: o controle reside no cdigo do
programa.
Sistemas baseados em eventos: o controle reside em um despachante ou monitor
provido pela linguagem, subsistema ou sistema operacional.
Sistemas concorrentes: o controle reside de modo concorrente em diversos objetos
independentes, sendo cada um uma tarefa separada. Uma tarefa pode esperar pelas
entradas, mas as outras continuam. O sistema operacional resolve os conflitos de
escalonamento entre tarefas.
f) Tratar das condies limites

Por exemplo, falhas: deve-se determinar as sadas para os casos de erros fatais.
g) Ajustar o equilbrio das prioridades

Deve-se determinar qual a importncia relativa dos diversos critrios a serem adotados
uma vez que h metas desejveis mas inviveis por algum motivo.
O documento de projeto de sistema gerado a partir desta etapa dever conter a

estrutura bsica do sistema e as decises estratgicas de alto nvel
III.3 PROJETO DE ARQUITETURA
O Projeto de Arquitetura tem como objetivo principal o desenvolvimento de uma

estrutura de programa modular e representar os relacionamentos de controle entre os
mdulos. Este projeto funde a estrutura de programa e a estrutura de dados, definindo
interfaces que possibilitam que os dados fluam atravs do programa.
Os mtodos de projeto encorajam o engenheiro de software a se concentrar no

projeto arquitetural antes de se concentrar nos demais detalhes.
Cada mtodo de projeto introduz uma heurstica e uma notao nicas, bem como
uma viso do que considera como qualidade de projeto. Contudo cada um desses mtodos
tem uma srie de caractersticas em comum:
Um mecanismo para a traduo da representao do domnio da informao

numa representao de projeto
Uma notao para representar os componentes funcionais e suas interfaces.
Heursticas para refinamento e diviso em parties
Diretrizes para avaliao da qualidade
O mtodo apresentado a seguir o Projeto Estruturado descrito em [Page-Jones-

88]
_____________________________________________________________________________________
_____________________________________________________________________________________
III.3.1 NOTAO PARA REPRESENTAR A ESTRUTURA DE UM PROGRAMA
Mdulo:
Chamada:
A
Chefe (Mdulo A chama mdulo B)
Chamada
B
Subordinado (Mdulo B executa sua funo e o controle
retorna ao comando em A imediato ao da chamada de B)
Continuao:
X1
X1
Iterao:
C1 Mdulo A chama B enquanto C1 verdadeira
Seleo:
_____________________________________________________________________________________
Apostila - Engenharia de Software: Introduo 20
_____________________________________________________________________________________
C2 Se C2 for verdadeira ento A chama B
Tipos de interface:
Item de dado Item de controle
A seguir apresentado um exemplo de estrutura de programa utilizando a notao

descrita acima. Mdulos que contm duas linhas so mdulos que esto sendo reusados.
_____________________________________________________________________________________
_____________________________________________________________________________________
III.3.2 QUALIDADE DE UM BOM PROJETO
A qualidade do projeto pode ser avaliada atravs dos seguintes critrios:
Coeso
Acoplamento
Fatorao
Diviso da deciso
Fan-out
Fan-in
A)
COESO
a medida de quanto os elementos de um mdulo esto relacionados.
A idia que os componentes de um sistema reunidos num mdulo sejam muito
relacionados entre si.
Tipos de coeso:
Coincidental:
Os elementos no se relacionam, parecendo que foram organizados de forma
arbitrria. O motivo pode ser, por exemplo, para se ter um tempo de resposta melhor.
Lgica:
Os elementos foram logicamente colocados juntos. Isto eles executam uma classe
de funes similares ou relacionadas,.
Ex: mdulo de entrada de dados, de tratamento de erros, de validao
Conseqncia: Passagem de parmetros de controle. Provoca acoplamento de
controle.
Temporal:
Os elementos do mdulo esto relacionados logicamente no tempo, ou seja, esto
reunidos por serem realizados num mesmo momento. Esta coeso melhor que a lgica
porque neste caso todos os elementos so executados.
Procedimental:
Os elementos do mdulo realizam funes diferentes e esto unidos por afinidade
de controle. Os elementos esto juntos para aproveitar por exemplo um loop. Os dados
passados e os dados recebidos possuem pouca ou nenhuma relao entre si.
Comunicacional:
Os elementos do mdulo operam o mesmo arquivo ou dados de entrada e sada.
Requer passagem de controle.
Ex: mdulo que l, inclui, exclui e modifica registro em um arquivo.
Atividades do mdulo podem ser independentes e executadas em qualquer ordem.
Seqencial:
Os elementos cumprem funes diferentes nas quais os dados de sada de um
elemento so a entrada para o elemento seguinte.
_____________________________________________________________________________________
_____________________________________________________________________________________
Ex: ler dados, calcular salrio e imprimir
Funcional:
Os elementos executam uma s funo.
Ex: calcular fatorial
B) ACOPLAMENTO
o grau de interdependncia entre dois mdulos.
O objetivo minimizar o acoplamento, tornando os mdulos to independentes
quanto possvel. Um acoplamento baixo, entre mdulos, indica um sistema bem particionado.
Pode ser obtido de 3 maneiras:
Eliminando relaes desnecessrias
Reduzindo o nmero de relaes necessrias
Enfraquecendo a dependncia das relaes necessrias
Para que se quer acoplamento fraco ?

Quanto menos conexes entre mdulos, menor a chance do efeito em cadeia (um
erro num mdulo aparece como sintoma num outro).
Queremos ser capazes de trocar um mdulo com um mnimo de risco de trocar
outro mdulo
Tipos de acoplamento:
Dados
Quando os mdulos se comunicam por parmetros, sendo cada parmetro um dado
nico ou uma tabela homognea (uma tabela na qual cada entrada contm o mesmo tipo de
informao)
Imagem
Dois mdulos so ligados por imagem se eles se referem mesma estrutura de
dados (um grupo composto de dados, como um registro)
Problema: quando envio para um mdulo um registro completo no qual s alguns itens
de dados sero usados estou arriscando que os outros itens sofram alterao. O ideal
enviar somente o que necessrio a cada mdulo.
Controle
Dois mdulos so acoplados por controle se um passa para o outro um grupo de
dados destinados a controlar a lgica interna do outro.
Comum
Quando dois mdulos se referem a mesma rea de dados. O fato de vrios mdulos
poderem acessar a mesma rea de dados dificulta a manuteno j que quando h um erro
fica difcil saber quem foi o responsvel. Dificulta tambm a reutilizao porque o mdulo
usa um nome de varivel fixo.
Se o tamanho de um dado global tem que ser mudado, como saber os mdulos que
sero afetados ?
Contedo
_____________________________________________________________________________________
_____________________________________________________________________________________
Quando um mdulo desvia a seqncia de instrues para dentro de outro ou quando

um mdulo altera um comando do outro.
c) Fatorao:
a separao de uma funo contida em um mdulo em um novo mdulo prprio.
Objetivos:
Evitar de se ter a mesma funo em mais de um mdulo
Tornar o sistema mais compreensvel
Permitir modificaes mais localizadas
d) Diviso da deciso
Uma deciso tem duas partes:
O reconhecimento de qual ao tomar
A execuo da ao
Quando o reconhecimento e a ao no se encontram no mesmo mdulo h uma

diviso da deciso.
Recomendao: A execuo deve ser mantida to perto quanto possvel do
reconhecimento para que a informao reconhecida no tenha que percorrer um longo
caminho (normalmente como um flag migrante) para ser processada.
e) Fan-out
Representa o nmero de subordinados de um mdulo. Recomenda-se um nmero de 7
+ 2 subordinados.
f) Fan-in
Representa o nmero de superiores imediatos que um mdulo possui. Quanto maior o
nmero de superiores melhor.
III.4 PROJETO DE DADOS
O Projeto de Dados tem uma profunda influncia sobre a qualidade do software e

os conceitos de ocultao de informao e abstrao de dados oferecem as bases para
este projeto.
Princpios que podem ser usados, segundo Wasserman, para projetar dados
[Pressman-95]:
Refletir sobre as diferentes organizaes de dados possveis de forma a decidir sobre
a mais apropriada
Todas as estruturas de dados e as operaes a serem executadas em cada uma devem
ser identificadas
Um dicionrio de dados deve ser estabelecido e usado para se definir tanto o projeto
de programa como o de dados.
Decises de baixa prioridade referentes ao projeto de dados devem ser proteladas at
mais tarde no processo de projeto
A representao da estrutura de dados deve ser conhecida somente por aqueles
mdulos que precisam fazer uso direto dos dados contidos na estrutura.
_____________________________________________________________________________________
_____________________________________________________________________________________
Uma biblioteca de estruturas de dados teis e das operaes que podem ser aplicadas a
elas deve ser desenvolvida. Estruturas de dados podem ser projetadas para se ter
reuso. Uma biblioteca de padres de estruturas de dados (tipos abstratos de dados)
pode reduzir tanto o esforo de especificao como o de projeto de dados.
Uma linguagem de programao e projeto de software deve suportar a especificao e
realizao de tipos abstratos de dados.
Tipos Abstratos de Dados:
Abstrao de dados: uma coleo designada de dados que descreve um objeto

de dados. Por exemplo, cheque de pagamento um objeto de dados que representa vrias
informaes diferentes: nome da pessoa a quem se paga, quantia bruta paga, imposto
retido, imposto de renda, contribuio para a previdncia, etc..
Contudo podemos nos referir a todos os dados ao declararmos o nome da abstrao

de dados.
A abstrao de dados possibilita que o projetista represente um objeto de dados
em nveis variveis de detalhe e, o que mais importante, que ele especifique um objeto de
dados no contexto das operaes que podem ser aplicadas a ele.
Quando usamos o tipo real para representar nmeros reais estamos usando uma
abstrao de dados, sem saber muito sobre a representao deste tipo no computador.
(Esta representao varia de um para outro computador). Para usar um objeto de dados no
programa cliente deve-se declarar a varivel como daquele tipo.
Logo que uma abstrao de dados definida, um conjunto de operaes que podem
ser aplicadas a ela tambm pode ser definido.
Quando escrevermos um programa cliente que utiliza esse objeto de dados no

necessitamos saber dos detalhes de implementao do objeto de dados. Basta que sejam
utilizados os operadores escritos. Isto ocultar informao (information hiding).
Ocultar informao til tambm devido a facilidade de se modificar o objeto de

dados, escolhendo-se por exemplo, um mtodo mais eficiente de representao ou de
implementao. Uma vez que o mdulo cliente acessa o objeto de dados somente atravs de
seus operadores, o mdulo cliente no precisar ser escrito novamente j que acessa o
objeto de dados atravs de seus operadores.
Vrias linguagens tm mecanismos que permitem a criao de tipos abstratos de

dados (combinao de um tipo de dado com seus operadores), que usado como um padro
ou estrutura de dados genrica a partir da qual outras estruturas de dados podem ser
representadas por uma instncia.
No Pascal podemos implementar cada tipo abstrato de dados numa unit.
_____________________________________________________________________________________
_____________________________________________________________________________________
Objetos so um meio natural de implementar tipos abstratos de dados. Tipos

objeto podem ser definidos de forma que os campos de dados sejam manipulados somente
por seus operadores. Em nosso prximo curso, Engenharia de Software II, ser enfocada a
abordagem baseada em objetos.
III.5 PROJETO DE INTERFACE
A seguir apresentado o resumo de uma pesquisa em qualidade de interfaces

homem-mquina realizada pela turma de Eng. de Software I do segundo perodo de 1998
a) Introduo
Ao criarmos uma aplicao, um dos detalhes mais importantes que devem ser considerados
a interface com o usurio. Por qu ? Porque uma interface feia ou difcil de ser entendida
e usada pode ser a linha que divide o sucesso do fracasso no ramo de software
Pesquisa de Leonardo, Maria, Flvio e Ricardo
Quando se faz o design de uma aplicao, um certo nmero de decises precisa ser feito
em relao interface. Qual estilo deve ser usado ? Quantas telas diferentes sero
necessrias? Que comandos sero includos nos menus? H necessidade de botes para
duplicar as operaes de menus ? E quanto s caixas de dilogo para interao com o
usurio ? Quanta assistncia deve ser dada em determinados momentos ?
Pesquisa de Luciano Leal, Rodrigo e Fabrcio.
Cada uma das seguintes reas relevante para a definio e o estudo de interfaces:
Cincia da Computao: fornece a estrutura tecnolgica.
Psicologia: preocupa-se com o entedimento do comportamento humano, percepo, cognio
etc.
Ergonomia: envolve-se com aspectos fsicos da adaptao das mquinas para uso humano.
Lingstica: a interao homem-mquina exige uma linguagem.
Sociologia: preocupa-se com o impacto dos sistemas interativos na estrutura da sociedade.
Desenho grfico e tipografia: a habilidade esttica dessas reas importante j que a
apresentao da interface torna-se bonita aos olhos dos usurios
Pesquisa de Ercole e Isaac
Os programadores esto indubitavelmente familiarizados com os aspectos tecnolgicos

dos computadores. fcil esquecer que muitos usurios no entendem (e provavelmente
no se importam) com a tecnologia por trs da aplicao. Eles vem o sistema como um meio
para um fim: uma maneira de realizar uma tarefa, idealmente mais facilmente do que
fariam sem a ajuda do computador....
imprescindvel ento, para um bom design da interface da aplicao, ter sempre o usurio
final em mente
b) Critrios de qualidade de interface homem-mquina
_____________________________________________________________________________________
_____________________________________________________________________________________
b.1) Conduo
Presteza, guiando o usurio e poupando-o do aprendizado de uma srie de

comandos
Dirigir a entrada de dados indicando o formato adequado e os valores aceitveis. Ex:
(--/--/--)
Exibir as unidades de medidas dos dados a digitar. Ex: m, cm
Indicar todas as informaes sobre o estado da interao
Para cada campo de dados, fornecer um rtulo
Indicar o tamanho do campo, quando ele limitado. ex: [_______]
Dar um ttulo a cada janela
Agrupamento /distino entre itens por localizao

Organizar as opes nos menus em funo dos objetos aos quais elas se aplicam
Agrupamento por formato

Fazer uma distino visual clara de reas que tm diferentes funes (rea de
comandos, rea de mensagens, etc.)
Feedback imediato e de qualidade s aes dos usurios

Todas as entradas dos usurios devem ser mostradas, com exceo de dados sigilosos.
Mesmo neste caso, cada entrada deve produzir um feedback perceptvel (por exemplo,
smbolos como *)
Caso o usurio interrompa um processamento de dados, deve ser mostrada uma
mensagem garantindo ao usurio que o sistema voltou ao seu estado prvio.
Quando o processamento longo, informaes sobre o estado do processamento devem
ser fornecidas. Ex: barra indicativa de tempo.
Legibilidade
Quando o espao para o texto for limitado, mostrar poucas linhas longas ao invs de
muitas linhas curtas.
Exibir texto contnuo em colunas largas de, ao menos, 50 caracteres por linha.
Ao exibir um texto, mantenha as palavras intactas, com o mnimo de hfens.
Cores devem ser usadas moderadamente
Se a cor est sendo usada para ressaltar algo na tela seria bom ter um outro indicador,
j que h usurios daltnicos
Uma tela com 2 ou 3 fontes tem um aspecto melhor do que com 5 ou 6.
B.2) CARGA DE TRABALHO
Minimize o nmero de passos para se fazer uma seleo em menu. (A profundidade do

menu no deve ser grande)
No faa o usurio entrar com dados que poderiam ser gerados pelo computador (dados
derivados)
Para entrada de dados, exiba os valores default atuais nos campos apropriados
Quando vrias pginas estiverem envolvidas, torne possvel ir diretamente para uma
pgina sem ter que passar pelas intermedirias. Ex: uso de abas
Os usurios no devem necessitar lembrar de dados exatos de uma tela para outra.
_____________________________________________________________________________________
_____________________________________________________________________________________
B.3) CONTROLE DO USURIO
Possibilitar aos usurios interromper ou cancelar a transao ou processo atual.

Fornecer uma opo cancelar com o objetivo de apagar qualquer mudana que acabou de
ser feita e trazer a tela para seu estado anterior.
B.4) ADAPTABILIDADE
Flexibilidade
Quanto mais formas de efetuar uma tarefa existirem, maiores sero as chances de que
o usurio possa escolher e dominar uma delas no curso de sua aprendizagem
Fornecer meios para que o usurio controle a configurao das telas
Considerao da experincia do usurio

Prever atalhos
Prever a escolha de entradas simples ou mltiplas de acordo com a experincia do
usurio
Fornecer um tutorial passo a passo para os usurios novatos
O usurio deve poder escolher o nvel de detalhe das mensagens de erro em funo de
seu nvel de conhecimento
b.5) Gesto de erros (entrada de dados incorretos ou com formatos inadequados,

entradas de comandos com sintaxe incorreta)
Proteo contra os erros

prefervel detectar erros na digitao do que no momento da validao.
Qualidade das mensagens de erro

As mensagens de erro podem favorecer o aprendizado, indicando ao usurio a razo ou
a natureza do erro cometido, o que ele fez de errado, o que deveria ter feito e o que
ele deve fazer.
Adotar um vocabulrio neutro, no personalizado, no repreensivo nas mensagens de
erro. Evitar o humor.
Correo dos erros

Quando se verifica um erro proporcionar ao usurio a possibilidade de refazer a
digitao apenas da parte equivocada, evitando rejeitar um bloco todo j digitado.
Deve ser possvel refazer um contexto anterior execuo de um comando (undo) e
cancelar uma operao.
b.6) Consistncia
Os procedimentos, rtulos, comandos, etc, so melhor reconhecidos, localizados e

utilizados quando seu formato, localizao ou sintaxe so estveis de uma tela para
outra, de uma seo para outra.
_____________________________________________________________________________________
_____________________________________________________________________________________
Desabilitar em vez de remover um item faz com que os usurios construam modelos
mentais de como a aplicao funciona
A consistncia diminui os custos de treinamento e suporte
b.7) Significado de denominaes
Termos pouco expressivos para o usurio podem ocasionar problemas de conduo,

podendo lev-lo a selecionar uma opo errada.
Recomenda-se o uso de metforas, procurando-se entender como o usurio v um
determinado aspecto. Ex: a tesoura significa corte e a lata de lixo simboliza jogar
fora.
B.8) COMPATIBILIDADE
Os procedimentos necessrios ao cumprimento da tarefa devem ser compatveis com as

caractersticas psicolgicas do usurio e devem respeitar suas expectativas ou
costumes.
Pesquisa de Alexandre Maia e George/Bruno, Leandro e Patricia/

Eduardo, Fabio e Robson/Michele e Sergio Ricardo/
Jorge e Marcio/Fabio Henrique/Jaime/Fabiano e Flvio
C) CUSTOS
Em recente pesquisa sobre dezenas de projetos, verifica-se que em mdia 48% do cdigo
de um sistema interativo dedicado interface. Quanto ao tempo de projeto de todo o
sistema, 50% de toda a implementao e 37% da manuteno ....
Economias da ordem de milhes de dlares podem ser realizadas em interfaces onde o
usurio comete poucos erros, o tempo de descrio das tarefas a serem realizadas
mnimo, a distrao do usurio reduzida e os treinamentos so eliminados. Ou seja, a
interface interfere economicamente na utilizao de um sistema
Pesquisa de Ercole e Isaac
D) FUTURO
O caminho da evoluo da interface claro para todos os que esto de alguma forma
ligados indstria de informtica: a sada definitiva a interface verbal, em que os
usurios possam dizer aos computadores o que fazer....
Como acontece com toda nova tecnologia, difcil adivinhar quais sero as conseqncias do
advento de uma interface verbal, mas podemos divisar com clareza pelo menos duas. Para
comear, a curva de aprendizado se tornar extremamente suave, conquistando muitos
daqueles que hoje costumam desprezar os computadores mais por insegurana ou preguia
do que por ideologia. Alm disso, o teclado no vai deixar de existir, mas deixar de ser um
fator determinante na utilizao dos computadores.
_____________________________________________________________________________________
_____________________________________________________________________________________
IV. FASE DE VERIFICAO, LIBERAO E MANUTENO
Esta a ltima etapa do processo de desenvolvimento e manuteno descrito na

seo I.6. Inclui a realizao de testes de unidades, integrao e validao, a liberao e
distribuio e por fim a manuteno do sistema. Nesta apostila sero abordadas
estratgias para realizao de teste de software e a manuteno.
IV.1 ESTRATGIAS DE TESTE DE SOFTWARE
No raro que uma organizao de software gaste 40% do esforo total de

projeto em teste. A atividade de teste de software de sistemas dos quais dependem vidas
humanas (por exemplo, controle de vo, monitorao de reatores nucleares), pode custar
de trs a cinco vezes mais que todos os outros passos de engenharia de software juntos !
[Pressman-95]
Teste: atividade que visa avaliar uma caracterstica ou recurso de um programa ou sistema
de software atravs de sua execuo.
Qualquer estratgia de teste de software deve incluir as seguintes atividades:

Projeto de casos de teste: devem ser projetados casos de teste que tenham a mais alta
probabilidade de descobrir a maioria dos erros com uma quantidade mnima de tempo e
esforo. Estes casos devem constar do Plano de Teste.
Execuo de teste: Para a realizao dos testes deve-se ter a mo o Plano de Teste.
Aps a realizao dos testes, os resultados devem ser comparados com os resultados
esperados. Quando h erro deve-se realizar a depurao. Depurao: a parte mais
imprevisvel do processo de teste. Um erro pode demorar uma hora, um dia ou um ms
para ser diagnosticado e corrigido.
Coleta e avaliao de dados: medida que os resultados de teste so reunidos e
avaliados, uma indicao qualitativa da qualidade e da confiabilidade do software
comea a vir tona.
Caso de teste: um conjunto especfico de dados de entrada e condies de arquivos,

juntamente com os resultados esperados, relacionados a um determinado objetivo.
Plano de teste: um documento organizado que contm para cada caso de teste as seguintes
informaes:
Objetivo do teste e que parte do sistema ser verificada
Onde e quando o teste ser realizado
Descrio do caso de teste
Procedimentos operacionais
Uma estratgia de teste:

Inicialmente os testes focalizam cada mdulo individualmente. Estes testes so
conhecidos como testes de unidades. Em seguida os mdulos devem ser montados ou
integrados para formarem um pacote de software. So realizados, ento, os testes de
integrao. Depois que o software foi integrado, um conjunto de testes de alto nvel
realizado. Esses testes de alto nvel so os testes de validao e de sistema.
_____________________________________________________________________________________
_____________________________________________________________________________________
Testes de Unidade:
Tm como objetivo testar os mdulos do programa
Abordagens para seleo dos casos de teste:
Funcionais: independentes da lgica da codificao (Teste caixa preta): A idia
que conhecendo-se o objetivo do mdulo, testes podem ser realizados para
demonstrar que cada funo totalmente operacional.
Estruturais: obtidos a partir da estrutura do programa (Teste caixa branca): A
idia que conhecendo-se o funcionamento interno de um mdulo, testes podem ser
realizados para garantir que todas as engrenagens se encaixam, ou seja, que a
operao interna do mdulo tem um desempenho de acordo com as especificaes e
que os componentes internos foram adequadamente postos prova.
Limites e situaes extremas
Necessita-se muitas vezes de stubs e drivers. Driver um programa principal que
aceita dados de caso de teste, passa tais dados para o mdulo ser testado e imprime os
dados relevantes. Os stubs servem para substituir mdulos que estejam subordinados
ao mdulo a ser testado. Um stub, ou programa simulado, usa a interface do mdulo
subordinado, pode fazer manipulao de dados mnima, imprime a verificao e retorna.
O teste de unidade simplificado quando um mdulo com elevada coeso projetado.
Quando somente uma funo endereada por um mdulo, o nmero de casos de teste
reduzido e os erros podem ser mais facilmente previstos e revelados.
Testes de integrao:
Tm como objetivo testar interfaces.
Apesar de todos os mdulos funcionarem corretamente individualmente, podem surgir
problemas ao serem colocados juntos. Dados podem ser perdidos ao longo de uma
interface; um mdulo pode ter um efeito inesperado, sobre outro; as subfunes
quando combinadas, podem no produzir a funo principal esperada; uma impreciso
individualmente aceitvel pode ser ampliada at nveis inaceitveis; as estruturas de
dados globais podem apresentar problemas. Etc...
No bom testar tudo junto j que fica difcil determinar as causas de erros
encontrados. Pode-se adotar uma estratgia de integrao incremental. O programa
construdo e testado em pequenos segmentos, ficando mais fcil isolar os erros e
corrigi-los.
Testes de Sistema:
Visam a realizao de uma srie de testes de forma a observar se os elementos do
sistema foram adequadamente integrados, se esto realizando as funes
especificadas e se o desejado desempenho global do sistema foi atingido.
Podem ser realizados os seguintes tipos de teste:
a) Recuperao: Este teste fora o sistema a falhar de diversas maneiras e verifica
se a recuperao adequadamente executada. Verifica, por exemplo, se o
tempo mdio at o reparo se encontra dentro dos limites aceitveis.
b) Segurana: Verifica se todos os mecanismos de proteo do sistema o protegero
de fato no caso de acessos indevidos.
c) Stress: Realizado para verificar como o sistema se comporta em situaes de
stress. Exemplo:
Testes que gerem um nmero maior de interrupes do que a mdia esperada.
_____________________________________________________________________________________
_____________________________________________________________________________________
Testes em que os ndices de entrada de dados so aumentados.

Testes que exigem o mximo de memria ou outros recursos.
Testes que provocam procura excessiva por dados.
Testes de aceitao ou validao:

Tm como objetivo demostrar que o sistema est pronto para ser colocado em
operao.
Quem dir que o sistema est pronto ? Depende do que foi definido na Especificao
de Requisitos com relao aos critrios de validao.
Escolha dos casos de teste: a cargo dos usurios com a assessoria tcnica dos
responsveis pelos testes
Pode ser realizado em um ou mais dias de trabalho usando os dados reais num
processamento em paralelo ao sistema atual
Se o software for desenvolvido como um produto a ser usado por muitos clientes,
torna-se pouco prtico realizar testes de aceitao com cada um. Usa-se ento um
processo denominado teste alpha e teste beta.
Teste alpha: Realizado por um cliente nas instalaes do desenvolvedor.
Teste beta: Realizado em uma ou mais instalaes do cliente pelo usurio final
do software. O desenvolvedor normalmente no est presente.
Organizao para a realizao de teste de software:
A atividade de teste realizada pela equipe de desenvolvimento do software e para

grandes projetos por um grupo de teste independente.
Como qualquer construtor, o engenheiro de software sente-se orgulhoso do
edifcio que construiu e parece olhar de esguelha para qualquer um que tente derrub-lo.
Quando os testes iniciam h uma sutil, mas definida, tentativa de quebrar o que o
engenheiro de software construiu. Do ponto de vista do construtor, a atividade de teste
pode ser vista psicologicamente com destrutiva. Sendo assim, o construtor pisa de leve
projetando e executando testes que demonstrem que o programa funciona em vez de
descobrir erros. Infelizmente os erros estaro presentes. Em se o engenheiro de software
no os encontrar, o cliente o far ! [Pressman-95]
Assim, necessria a conscincia de que melhor encontrar antes os erros. A
equipe de desenvolvimento sempre responsvel por testar os mdulos do programa, para
garantir que cada uma execute a funo para a qual foi projetada. Em muitos casos a equipe
de desenvolvimento tambm realiza testes de integrao. S depois que a arquitetura de
software est completa que um grupo de teste independente poder envolver-se. Este
grupo deve trabalhar unido ao longo do projeto de software a fim de garantir que testes
cuidadosos sejam levados a efeito. Enquanto a atividade de teste realizada, a equipe de
desenvolvimento deve estar disposio para corrigir erros que sejam descobertos pela
equipe de testes.
Concluso:
Realizar testes uma atividade difcil e criativa
Testes atuam tambm prevenindo erros
Testes devem ser planejados
Realizar teste exige independncia
_____________________________________________________________________________________
_____________________________________________________________________________________
O armazenamento de informaes, como quantidade e tipo de erros encontrados

durante o desenvolvimento e a manuteno, fundamental na determinao da
qualidade de programas e sistemas que venham a ser desenvolvidos.
IV.2 MANUTENO
O crescimento da demanda de software levou evoluo que hoje pode ser

observada na indstria de software, mas tambm levou a um srio problema: a manuteno
das aplicaes.
O que manuteno ?
A manuteno o conjunto de atividades que visa alterar o software depois que ele
foi liberado para o usurio e colocado em operao.
O que pode ser observado na indstria de software que ela no est preparada
para lidar com a atividade de manuteno. Os custos de manuteno tem sido altssimos:
nos anos 80 de 40 a 60 % do oramento para sofware foi gasto em manuteno e para os
anos 90 estima-se que o gasto ser de 70 a 80 %.
Alm desse h outros custos difceis de serem medidos como:
- a insatisfao dos usurios com a demora das modificaes;

- a reduo da qualidade do software, devido s mudanas ocorridas que introduzem
erros latentes;
- atrasos no desenvolvimento de novos sistemas.
O que fazer ?
A questo no acabar com a manuteno, j que ela faz parte do ciclo de vida do
software. Os sistemas de software so dinmicos estando sempre em evoluo.
Comparando-se o software com organismos vivos e fenmenos naturais observa-se
que:
- Como organismos vivos e fenmenos naturais, projetos de software seguem um

ciclo de vida com um rpido crescimento durante a infncia, passam por um longo perodo de
maturidade e depois comeam um ciclo de decadncia. O final do projeto de software sua
sada de produo.
- O perodo de gestao do projeto de software proporcional ao tamanho do

sistema final; isto , grandes sistemas tm um longo perodo antes de serem liberados,
como grandes animais tendem a ter longos perodos de gestao.
- A expectativa de vida da aplicao em produo proporcional ao tamanho.

Pequenas aplicaes freqentemente desaparecem de bibliotecas de produo em um ou
dois anos, enquanto grandes aplicaes tendem a existir durante 10 a 15 anos ou mais. Isto
tambm se assemelha a fenmenos naturais, onde a expectativa de vida dos animais
proporcional sua massa.
_____________________________________________________________________________________
_____________________________________________________________________________________
- Uma vez que uma aplicao entra em produo, ela continua a acrescentar novas
funes e facilidades num ritmo relativamente constante entre 5 a 15 % de nova
funcionalidade por ano. Este fenmeno parece similar ao ganho em massa de vrios
organismos vivos durante a infncia e a adolescncia.
- A entropia (medida do caos num sistema) dos sistemas de software aumenta com o
tempo. Isto equivalente a dizer que vrias pequenas mudanas gradualmente degradam a
estrutura inicial do projeto de software e aumentam sua complexidade. Este fenmeno
verdade em todas as entidades orgnicas naturais, de forma que a sua descoberta em
software no uma surpresa.
- Intervenes preventivas e corretivas podem atrasar o incio da entropia de

sistemas de software e estender o perodo antes que a substituio se torne mandatria.
Isto mais ou menos equivalente ao que ocorre em organismos naturais em que a
interveno preventiva e corretiva pode atrasar o incio ou agravamento de algumas formas
de doenas.
Uma vez que os sistemas evoluem e que a manuteno portanto necessria, o que
fazer para diminuir os custos, o que pode ser melhorado? Porque a manuteno tem sido
encarada como um problema ?
Observa-se o seguinte:
- Muito software gerado sem preocupao com a gerao de algo com qualidade e
que possa no futuro ser facilmente modificado. Isto torna muito difcil a tarefa da
manuteno.
Por exemplo, muito difcil entender o programa que outros fizeram quando no
foram seguidas normas de documentao. No se pode tambm esperar que aquele que
desenvolveu o programa dar suporte pelo fato de haver muita mobilidade na rea.
A necessidade de documentao um fato. No entanto, essencial que ela seja

facilmente entendida e consistente com o cdigo fonte para ter algum valor.
- A manuteno no tem sido vista como uma tarefa nobre. Muito deste sentimento
vem do alto nvel de frustrao associado com o trabalho de manuteno.
Sem dvida uma sada para diminuir os problemas da manuteno melhorar o

processo de desenvolvimento no sentido de construir um software com qualidade.
O fato que atualmente o software que ainda est em operao possui problemas
srios, o que faz aumentar o nmero de pessoas envolvidas na atividade de manuteno.
Em meados dos anos 80 foi realizada uma pesquisa nos EUA onde se constatou que
por volta de 3000 de um total de 7000 profissionais de software estavam envolvidos em
atividades de manuteno. Isto significa que 43 % do pessoal estava trabalhando com a
manuteno.
Voc j considerou a possibilidade de vir a trabalhar em manuteno? importante,

ento que se saiba:
_____________________________________________________________________________________
_____________________________________________________________________________________
que tipos de manuteno podem ser realizadas?

quais as atividades realizadas durante a manuteno?
quais os atributos de um sistema manutenvel ?
o que engenharia reversa e reengenharia ?
a) Tipos de manuteno
Corretiva: para corrigir um erro detectado.

Adaptativa: para adaptar o software por vrios motivos, como:
- surgimento de novas geraes de hardware;
- aparecimento de novos sistemas operacionais ou novas verses dos atuais;
- mudanas em equipamentos perifricos e outros elementos do sistema.
Aperfeioadora: para aperfeioar o software devido a recomendaes, normalmente
dos usurios, de que sejam acrescentadas novas capacidades, modificadas funes
existentes e realizadas melhorias gerais.
Preventiva: visa prevenir erros. Neste caso o software alterado para melhorar a
futura manutenibilidade. Esta atividade ainda raramente realizada.
Esses tipos de manuteno refletem caractersticas dos sistemas de software:

Mesmo aps a liberao do software para uso, ele pode conter erros, ou seja, pode no
estar atendendo completamente aos requisitos estabelecidos.
Ocorrem mudanas externas ao longo do tempo em que o software est em operao.
Ex: A introduo de um novo sistema operacional
Sistemas de software so dinmicos. Novas necessidades esto constantemente
surgindo.
b) Atividades realizadas durante a manuteno
As atividades realizadas devem estar de acordo com a Gerncia de Configurao

proposta. A Gerncia de Configurao de Software engloba o conjunto de atividades de
acompanhamento e controle de modificaes durante todo o ciclo de vida.
Assim como o desenvolvimento do software, a manuteno inclui alm dos aspectos
tcnicos, os gerenciais e os de qualidade. Desta forma quanto mais bem definidos
estiverem estes aspectos, melhor ser conduzido o processo de manuteno.
Uma atividade que deveria ser realizada durante a manuteno a obteno de
informaes para posterior avaliao. Estas informaes representam medidas como por
exemplo, o tempo gasto para reconhecimento de um problema, o tempo gasto para realizar
a modificao, o tempo para realizao de testes, etc. So teis para avaliar a qualidade
do software com relao manuteno, a eficincia de mtodos usados, etc, alm de
possibilitar ao gerente ter ao longo do tempo uma srie de dados concretos de forma a
avaliar o efeito de medidas tomadas para melhorar a manutenibilidade.
c) Atributos de um sistema manutenvel
Manutenibilidade pode ser definida como a facilidade com a qual o software pode
ser entendido, corrigido, adaptado e/ou melhorado e testado.
Para isto o software deve ser modular, consistente, legvel, conciso (expressar algo
em poucas palavras), auto-descritivo, comunicativo, acessvel e extensvel.
_____________________________________________________________________________________
_____________________________________________________________________________________
difcil especificar o nvel de manutenibilidade desejado para um software. A

especificao dos nveis requeridos de coeso e acoplamento no projeto o que h de
melhor para se quantificar a manutenibilidade.
- Coeso poderia ser expressa como a mnima coeso aceitvel para cada mdulo
e a mnima aceitvel considerando-se a mdia de todos os mdulos no projeto.
- Acoplamento poderia ser expresso como o mximo aceitvel para qualquer par
de mdulos e o mximo aceitvel para todos os pares de mdulos do projeto.
Para os demais casos em que difcil quantificar um valor, como por exemplo, a
legibilidade, uma idia declarar na especificao de requisitos que devem ser seguidas
determinadas normas pr-definidas.
d) Engenharia Reversa e Reengenharia
De forma a realizar manutenes preventivas so utilizadas a engenharia reversa e

a reengenharia.
Engenharia Reversa: este termo tem suas origens no mundo do hardware. Uma
empresa desmonta um hardware comercializado, num esforo para entender os segredos de
projeto e manufatura do concorrente.
Em software a idia semelhante com a diferena que na maioria dos casos o
sistema que passar pela engenharia reversa no do concorrente e sim da prpria
empresa. So sistemas obscuros e a engenharia reversa ter como objetivo extrair
informaes do cdigo numa tentativa de gerar uma representao em um nvel de
abstrao mais alto do que o cdigo fonte.
Reengenharia: alm de recuperar informaes de projeto de um software
existente, usa essas informaes para alterar ou reconstituir um software existente de
forma a melhorar sua qualidade. O desenvolvedor pode tambm adicionar novas funes ou
melhorar o desempenho global.
V. PARADIGMAS DA ENGENHARIA DE SOFTWARE
Paradigmas da Engenharia de Software, ciclos de vida ou processo de

desenvolvimento e manuteno so termos que tm sido utilizados significando um conjunto
de etapas para elaborao de software. A seguir so descritos os modelos mais comentados
na literatura: o modelo de codificao e ajuste, o modelo cascata, a abordagem incremental
ou evolutiva, a prototipagem descartvel, as tcnicas de quarta gerao e o modelo espiral.
a) Modelo de codificao e ajuste
Modelo utilizado no incio da computao

Modelo consiste na iterao de dois passos:
Escrever o cdigo numa linguagem de baixo nvel
Ajustar o cdigo de forma a eliminar erros ou acrescentar novas facilidades
No precisamente formulado e nem cuidadosamente controlado
Mostrou-se adequado porque:
Os problemas a serem resolvidos eram bem entendidos
O usurio era o prprio cientista ou engenheiro que desenvolvia sua aplicao (no
existia distino entre o programador e o usurio final)
_____________________________________________________________________________________
_____________________________________________________________________________________
Falhas do Modelo de codificao e ajuste levaram ao reconhecimento da chamada crise

do software.
Causas:
Computao passou a ser utilizada em vrios domnios de aplicao, nos quais
os usurios no entendem de computao
O tamanho e a complexidade do software aumentaram
O software gerado no atendia s expectativas dos usurios
O software passou a ser desenvolvido tambm para ser vendido a um
usurio especfico ou ao mercado em geral
Passou a haver maiores exigncias de qualidade
Como conseqncia:
Aspectos econmicos, organizacionais e psicolgicos tornaram-se
importantes
As fases de projeto e anlise surgiram como uma alternativa para resolver
alguns dos problemas: A fase de Projeto facilitava o gerenciamento da
complexidade e a fase de Anlise permitia um melhor entendimento dos
requisitos do usurio.
Nascimento da Engenharia de Software como disciplina.
Surgimento do conceito de ciclo de vida de software e de modelos que
descrevem o ciclo com mais preciso.
b) Modelo Cascata
Origem:
Na literatura surgiu na dcada de 50 como resultado da experincia obtida com o
desenvolvimento de um sistema de software de defesa area
Tornou-se popular na dcada de 70.
Descrio:
O processo estruturado como uma cascata de fases, onde a sada de uma constitui a
entrada de outra.
Cada fase composta por um conjunto de atividades que podem ser realizadas
concorrentemente.
Caractersticas do modelo:
Linear: o desenvolvimento do software procede linearmente do incio ao fim do
processo.
Rgido: Os resultados de cada fase so congelados antes de se passar para a prxima
fase.
Crticas:
Os projetos raramente seguem o fluxo seqencial que o modelo prope.
Tem dificuldade de acomodar a incerteza natural que existe no comeo dos projetos.
O cliente deve ter pacincia j que uma verso do trabalho s est disponvel num ponto
tardio do cronograma.
_____________________________________________________________________________________
_____________________________________________________________________________________
Estudo
de viabilidade
Anlise e especificao
de requisitos
Projeto e
especificao
Codificao e testes
de mdulos
Integrao e teste
de sistemas
Instalao
Manuteno
c) Abordagem incremental ou evolutiva
Uma abordagem rgida ou monoltica detalha completamente todos os aspectos de

uma etapa do desenvolvimento antes de partir para outra etapa. E nada colocado em
operao at o fim do desenvolvimento. J numa abordagem incremental, parte de alguns
estgios so adiadas de forma a se implementar logo um conjunto de funes.
A idia dessa abordagem que incrementos so liberados ao usurio logo que

desenvolvidos. Se incrementos so liberados ao usurio, devem consistir no somente de
cdigo e documentao de projeto mas tambm de documentao dirigida ao usurio.
Assim, podemos definir um incremento como uma unidade funcional de software contida em
si mesma que atende a algum objetivo do cliente juntamente com todo o material de
suporte: especificao de requisitos e projeto, planos de teste, manual do usurio e
material de treinamento.
Estratgia de desenvolvimento:
Liberar algo ao usurio
Medir o valor para o usurio em todas as dimenses crticas
Ajustar tanto o projeto como os objetivos baseado na realidade observada.
Essa definio da abordagem geral, podendo acomodar vrios modelos como por exemplo:
_____________________________________________________________________________________
_____________________________________________________________________________________
Implementao incremental
Desenvolvimento incremental
Implementao incremental:
O modelo cascata seguido at a fase de projeto. A implementao incremental.
Durante a anlise de requisitos e projeto h uma ateno especial com a identificao
de subconjuntos do sistema e com a definio de interfaces que permitiro que novos
subsistemas sejam acrescentados.
Isto leva a um plano onde diferentes partes so implementadas, testadas e liberadas
em diferentes momentos de acordo com a prioridade.
Desenvolvimento incremental:
O desenvolvimento comea analisando-se um incremento no nvel de requisitos. Cada
incremento ento separadamente projetado, codificado e testado, integrado e
liberado.
Desta forma o cascata seguido mas para cada incremento separadamente. O modelo
uma seqncia de mini-ciclos cascata.
Incrementos so desenvolvidos um aps o outro depois de ter sido recebido um
feedback do usurio.
necessria muita disciplina e um planejamento cuidadoso para evitar uma iterao no
proveitosa e um desenvolvimento que nunca termina.
d) Prototipagem descartvel
Exemplos de uso de prototipagem:

Um stub, prottipo de um componente real que ele simula para facilitar a realizao de
testes.
O prottipo de uma interface apresentado para que o cliente de forma a se poder
analisar melhor o tipo de interface desejado ou outros requisitos do sistema.
Nos casos em que o prottipo no evolui para o sistema final no h necessidade do
rigor no desenvolvimento exigido na abordagem incremental ou evolutiva descrita acima.
e) Tcnicas de quarta gerao

Possibilitam que o desenvolvedor de software especifique alguma caracterstica do
software num nvel elevado. A ferramenta gera, ento, automaticamente, o cdigo fonte.
Exemplos de ferramentas: linguagens no procedimentais para consulta a banco de
dados, gerao de relatrios, manipulao de dados, interao e definio de telas,
planilhas eletrnicas etc..
Ferramentas se aplicam a domnios muito especficos. No h nenhum ambiente de
quarta gerao que possa ser aplicado com igual facilidade a cada uma das categorias de
aplicao.
Passos:
Coleta de requisitos (se for uma pequena aplicao pode-se partir para a
implementao)
Estratgia de projeto
Implementao
Teste
_____________________________________________________________________________________
_____________________________________________________________________________________
f) Modelo Espiral
Tentativa, na dcada de 80, de reunir as melhores caractersticas do ciclo cascata

e da prototipao acrescentando um novo elemento: a anlise de risco.
Define quatro atividades principais que se repetem seguindo uma espiral:

Planejamento
Anlise dos riscos
Engenharia
Avaliao feita pelo cliente
g) Objectory
Desenvolvido por Booch, Jacobson e Rumbaugh, tambm conhecido por Rational

Unified Process.
CONSTRUO
TRANSIO
INCIO ELABORAO
1 2 3 ...
4
Este processo, apresentado em [Fowler-97] iterativo e incremental, propondo o

desenvolvimento em partes, atravs da realizao das seguintes atividades:
INCIO (inception)
O incio tem como objetivo o entendimento da rea de negcio e a deciso sobre o
escopo do projeto. necessrio realizar alguma anlise de forma a se avaliar custos e
benefcios. quando se obtm a aceitao do projeto. Pode ser realizada de diferentes
formas: uma conversa informal ou pode ser realizada atravs de um estudo de viabilidade
que levar semanas para ser concludo.
ELABORAO
Na elaborao obtm-se mais detalhes sobre os requisitos, elabora-se uma anlise e
projeto em alto nvel de forma a se obter um arquitetura base e cria-se o plano de projeto.
Devem ser avaliados os riscos do projeto:
Riscos relacionados aos requisitos: Qual o perigo de construir um sistema que no
satisfaa ao usurio?
Riscos relacionados tecnologia: Sero utilizados objetos ? Qual a experincia da
equipe no desenvolvimento orientado a objetos ?
Riscos relacionados capacidade da equipe: A equipe tem a experincia
necessria ?
Riscos polticos: H foras polticas que podem vir a afetar o projeto ?
A primeira e uma das mais importantes tarefas na fase de elaborao descobrir

os requisitos do sistema que est sendo construdo. Na prtica, no sero obtidos todos.
No entanto, deve-se procurar descrever os mais importantes, atravs de contatos com os
usurios do sistema.
_____________________________________________________________________________________
_____________________________________________________________________________________
CONSTRUO
A etapa de construo consiste de vrias iteraes, cada uma produzindo um
software com qualidade, testado e integrado e satisfazendo aos requisitos do projeto.
Cada iterao contm as etapas de anlise, projeto, implementao e testes.
TRANSIO
na etapa de transio em que so realizados os testes beta, melhoria de
desempenho e treinamento dos usurios.
Os projetos podem exigir um nvel de formalidade maior ou menor dependendo de

suas caractersticas. O projeto de um sistema bancrio exigir mais do que um sistema
para controle de emprstimos de uma vdeo locadora. Desta forma os fundamentos destas
fases ocorrero sempre, mas de diferentes formas.
VI. CASE
Case - Engenharia de Software auxiliada por computador

A oficina de Eng. de Software tambm denominada Ambiente Integrado de
Suporte a Projetos.
Caractersticas das melhores oficinas:

contm uma coleo de ferramentas teis que ajudam em cada passo da construo de
um produto. Esta coleo o CASE.
contm um layout organizado que possibilita que as ferramentas sejam encontradas
rapidamente e usadas eficientemente.
dispem de um arteso habilitado que entende como usar as ferramentas efetivamente.
Obs: Para dizermos que temos um CASE no necessrio que tenhamos todas as
ferramentas.
Dificuldades da rea
Se compararmos o CASE com o CAD/CAE/CIM que est muito mais evoludo,

podemos observar que o CAD/CAE/CIM implementou prticas de engenharia que foram
experimentadas e provadas ao longo dos ltimos 100 anos. Isto no ocorreu com o CASE
que apresenta um conjunto de ferramentas semi-automatizadas que esto implementando
uma cultura de engenharia que novidade para muitas empresas.
CASE hoje
Ferramentas individuais esto sendo usadas por algumas empresas.

H um srio esforo para integrar ferramentas individuais a fim de se formar um
ambiente consistente. H diversos tipos de integrao.
Hoje a tendncia no desenvolvimento de software est distante do computador
mainframe e caminha na direo da estao de trabalho como plataforma de engenharia
_____________________________________________________________________________________
_____________________________________________________________________________________
de software. Estaes de trabalho individuais so dispostas em redes, de forma que os

engenheiros de software possam comunicar-se efetivamente.
Taxonomia por funo
Ferramentas podem ser classificadas de vrias formas: por funo, pelo uso que
elas tm nas vrias etapas do processo de engenharia de software, pela arquitetura do
ambiente que as suporta, pelo custo, etc...
A seguir apresentada uma classificao por funo:
1. Planejamento de sistemas comerciais

Ajudam a melhorar a compreenso de como a informao flui entre as vrias unidades
organizacionais numa Empresa.
2. Gerenciamento de projetos
Oferecem apoio ao planejamento de projetos, rastreamento dos requisitos e captao de
mtricas.
3. Suporte
So ferramentas dos seguintes tipos:
Documentao
Software bsico
Garantia da qualidade
Bancos de dados
Gerenciamento de configurao
4. Anlise e projeto
Oferecem apoio para as atividades de anlise e projeto estruturado, possibilitam a
prototipao e simulao de sistemas e permitem o desenvolvimento de interfaces.
5. Programao
H ferramentas para codificao convencional, codificao de quarta gerao e para
programao orientada a objeto
6. Integrao e testes
H ferramentas que ajudam a derivar casos de teste, outras que interagem com o programa
enquanto ele est em execuo podendo at mesmo mudar o software analisado e visam
gerar informaes sobre o que est ocorrendo no programa.
7. Prototipao
8. Manuteno
Podem dar apoio Engenharia reversa ou Reengenharia
Integrao de ferramentas: I-CASE (CASE integrado)

Benefcios:
A transferncia harmoniosa de informaes (modelos, programas, documentos, etc)
_____________________________________________________________________________________
_____________________________________________________________________________________
A reduo do esforo para realizar atividade de controle de qualidade, controle de

configurao, documentao
Maior controle do projeto
Maior facilidade de coordenar os membros de uma equipe
Algumas das caractersticas de um I-CASE:

Oferecer um mecanismo para compartilha as informaes entre todas as ferramentas
do ambiente
Permitir que uma mudana efetuada num item de informao seja propagada para
outros itens relacionados
Oferecer controle de verso e gerenciamento de configurao
Permitir acesso direto, no seqencial a qualquer ferramenta contida no ambiente
Apoiar a comunicao entre os engenheiros de software
_____________________________________________________________________________________
_____________________________________________________________________________________
BIBLIOGRAFIA:
[Blaha-98] Blaha, Michael; Premerlani, William, Object-Oriented Modeling and Design

for Database Applications, Prentice Hall, 1998.
[Fowler-97] Fowler, Martin; Scott, Kendall; UML Distilled: applying the standard
object modeling language, Ed. Addison-Wesley, 1997.
[Ghezzi-91] Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli, Fundamentals of Software
Engineering, Prentice-Hall International,Inc, 1991
[Jacobson] Jacobson, Ivar e outros, Object-Oriented Software Engineering: a use case
driven approach, Ed. Addison-Wesley, 1996.
[Melo-97] Rubens Melo, Sidney Silva, A. Tanaka, Banco de Dados em Aplicaes Cliente-
servidor, Livraria e Editora Infobook, 1997.
[Page-Jones-88] Meilir Page-Jones, Projeto Estruturado de Sistemas, Ed. McGraw-Hill,
1988.
[Pressman-95] Roger S. Pressman, Engenharia de Software, Makron Books do Brasil
Editora, 1995.
[Rumbaugh-94] J.Rumbaugh, M.Blaha e outros, Modelagem e Projetos Baseados em
Objetos, Editora Campus, 1994.
[Yourdon-90] E. Yourdon, Anlise Estruturada Moderna, Ed. Campus, 1990.
_____________________________________________________________________________________

Engenharia de Software I

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software I

Enviado por

Direitos autorais:

Formatos disponíveis

ENGENHARIA DE SOFTWARE:

Esta apostila tem como objetivo descrever as principais atividades da Engenharia

Nesta primeira seo a Engenharia de Software introduzida, apresentando-se um

I.1 HISTRICO DA ENGENHARIA DE SOFTWARE [Ghezzi-91]

Primeiros tempos da computao:

Final da dcada de 50:

Meados dos anos 60 at a dcada de 70:

E assim a Engenharia de Software nasceu.

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

O estabelecimento e uso de slidos princpios de engenharia para que se possa obter

A Engenharia de Software abrange um conjunto de 3 elementos fundamentais:

Mtodos: proporcionam os detalhes de como fazer para construir o software. H mtodos

Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos mtodos.

Procedimentos: definem a seqncia em que os mtodos sero aplicados, quais os produtos

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

As estimativas de prazos e de custos freqentemente so imprecisas

J temos um manual repleto de padres e procedimentos para a construo de

Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho

Sistema: Um conjunto ou disposio de coisas relacionadas a ponto de formar uma unidade

Sistema baseado em computador: Um conjunto ou disposio de elementos organizados

Elementos de um sistema baseado em computador:

Sistemas de Informao baseados em computador: [Melo-97]

Em [Pressman-95] apresentada a seguinte lista de fatores que afetam a qualidade

Fatores relacionados operao do software:

Correo: O quanto o software satisfaz as especificaes e atende aos objetivos do

Fatores relacionados reviso do software:

Facilidade de realizar manutenes: O esforo requerido para localizar e corrigir um

Fatores relacionados evoluo do software:

Portabilidade: O esforo requerido para transferir um software de um hardware para

I.6 FASES DA ENGENHARIA DE SOFTWARE

A figura apresentada na pgina seguinte, de [Pressman-95], representa as fases

(a) Definio (descrita na seo II)

II. FASE DE DEFINIO [Pressman-95]

Definio a primeira etapa do processo de desenvolvimento e manuteno. Inclui o

II.1 PLANEJAMENTO DO PROJETO

O planejamento do projeto de desenvolvimento de software uma das atividades

Ao iniciar o planejamento do projeto importante que sejam definidos e

Estas informaes devem fazer parte do Plano do Projeto de Software, um

O Plano do Projeto de Software deve ser um documento simples e seu nvel de

Os recursos esto disponveis ?

O controle realizado pelo gerente de projetos de software para administrar os

O controle do projeto pode ser realizado de vrias maneiras:

II.2 ANLISE E ESPECIFICAO DE REQUISITOS

II.2.1 ATIVIDADES FUNDAMENTAIS, O ANALISTA DE SISTEMA E CAUSAS DE

A seguir so apresentadas as atividades consideradas fundamentais na anlise e

Objetivos e restries do projeto

O analista de sistemas tem como funo definir os elementos para um sistema

Consideraes de projeto (prazo, custo, etc)

Algumas das causas apontadas pelas dificuldades nesta rea so:

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

Podemos obter requisitos atravs de:

Utilize um estilo adequado:

Problemas que podem surgir:

FAST (Facilitaded Application Specification Techniques)

Muitas abordagens de FAST tm sido propostas com as seguintes diretrizes bsicas:

No encontro inicial entre o desenvolvedor e o cliente surgem perguntas e

Exemplo de FAST: JAD (Joint Application Development)

Mtodo desenvolvido e utilizado na IBM

II.2.3 REVISO DA ESPECIFICAO

Podem ser realizadas desde revises informais at as revises tcnicas formais.

As revises tcnicas formais (RTFs) atuam como filtros, purificando os produtos ao

H dois tipos de revises:

As RTFs so realizadas atravs de reunies. Independente do tipo da reviso toda

Antes da reunio de reviso so realizadas as seguintes atividades: