Apostilha ES2003

ENGENHARIA DE SOFTWARE
Rosario Girardi
UFMA
2002
Tabela de contedo
CAPTULO 1 -
INTRODUO ENGENHARIA DE SOFTWARE
1.1 ALGUMAS DEFINIES

1.2 OBJETIVOS DA ENGENHARIA DE SOFTWARE
1.3 A IMPORTNCIA DO SOFTWARE
1.4 O QU O SOFTWARE?
1.5 SISTEMA DE COMPUTAO
1.5.1 ELEMENTOS DE UM SC
1.5.2 EVOLUO DOS SISTEMAS DE COMPUTAO
1.5.3 EVOLUO NAS MODALIDADES DE PROCESSAMENTO DA INFORMAO
1.5.3.1 Processamento centralizado
1.5.3.2 Processamento distribudo
1.6 ELEMENTOS DA ENGENHARIA DE SOFTWARE
1.7 DETERIORO DO HARDWARE VS SOFTWARE
1.8 TIPOS DE SOFTWARE
1.9 A CRISE DO SOFTWARE
1.10 PROBLEMAS DO DESENVOLVIMENTO DE SOFTWARE
7
7
7
8
8
8
9
11
11
12
13
14
15
16
17
CAPTULO 2 -
MODELOS DE DESENVOLVIMENTO
2.1 O CICLO DE VIDA EM CASCATA

2.1.1 ANLISE U ENGENHARIA DE SISTEMAS
2.1.2 ANLISE DE REQUERIMENTOS DO SOFTWARE
2.1.3 PROJETO
2.1.4 CODIFICAO
2.1.5 PROVA
2.1.6 INTEGRAO
2.1.7 MANUTENO
2.2 CRTICAS AO CICLO DE VIDA EM CASCATA
2.3 CONTRIBUIES DO CICLO DE VIDA EM CASCATA
2.4 PARADIGMA DA PROTOTIPAO
2.4.1 QUANDO APLICA-LHO
2.4.2 VANTAGENS DA PROTOTIPAO
2.4.3 PROBLEMAS DA PROTOTIPAO
2.5 TCNICAS DA QUARTA GERAO
2.6 MODELO EM ESPIRAL
2.7 MTODOS, METODOLOGIAS E FERRAMENTAS DE DESENVOLVIMENTO
2.8 ENGENHARIA DE SOFTWARE BASEADA NA REUTILIZAO
2.9 FERRAMENTAS CASE
2.10 GROUPWARE
2.11 VISO GENRICA DO PROCESSO DE DESENVOLVIMENTO DO SOFTWARE
2.11.1 DEFINIO
Engenharia de Software
Prof. Rosrio Girardi
18
18
18
19
19
19
20
20
20
21
22
22
23
23
23
24
24
25
25
26
26
26
27
2
2.11.2
2.11.3
DESENVOLVIMENTO
MANUTENO
CAPTULO 3 -
ENGENHARIA DE SISTEMAS
3.1 TAREFAS DA ENGENHARIA DE SISTEMAS

3.1.1 IDENTIFICAO DAS NECESSIDADES DO CLIENTE E DEFINIO DE OBJETIVOS
3.1.2 ESTUDO DE VIABILIDADE
CAPTULO 4 4.1
4.2
4.3
4.4
4.5
4.6
ENGENHARIA DE REQUISITOS
PRINCIPAIS CONCEITOS
TIPOS DE REQUISITOS
PROBLEMAS DOS REQUISITOS
E.R. MOTIVAO
QUESTES MAIS FREQENTEMENTE PERGUNTADAS SOBRE REQUISITOS (FAQS)
A ENGENHARIA DE REQUISITOS E AS OUTRAS FASES DO CICLO DE
DESENVOLVIMENTO
4.7 FUNDAMENTOS DA ANLISE DE REQUISITOS
4.8 TAREFAS DA ANLISE DE REQUISITOS
4.8.1 RECONHECIMENTO DO PROBLEMA
4.8.2 COMPREENSO E REPRESENTAO DE DOMNIO
4.8.2.1 O domnio da informao

4.9 PRINCPIOS DA ANLISE DE REQUISITOS
4.9.1 DECOMPOSIO DO PROBLEMA
4.9.2 VISES LGICAS E FSICAS DOS REQUISITOS
4.10 A ESPECIFICAO DE REQUISITOS
4.10.1 PROPRIEDADES EMERGENTES
4.10.2 USURIOS DO DOCUMENTO DE REQUISITOS
4.10.3 A ESTRUTURA DO DOCUMENTO DE REQUISITOS
4.10.3.1 Adaptando um padro
4.11 CONSTRUO DE PROTTIPOS
4.11.1 PARADIGMA DA PROTOTIPAO
4.12 ROTEIRO PARA A ESPECIFICAO DE REQUISITOS
4.13 MTODOS PARA A ANLISE DE REQUISITOS
4.13.1 CLASSIFICAO DOS MTODOS PARA A ANLISE DE REQUISITOS
CAPTULO 5 -
INTERAO HUMANA - COMPUTADOR
5.1 CONCEITOS BSICOS

5.1.1 IMPORTNCIA DA HCI
5.1.2 REAS DE APLICAO
5.1.3 INTERFACE USURIO
5.1.4 FATORES HUMANOS
5.1.5 METFORAS
27
28
29
29
29
30
32
32
32
33
33
34
35
36
37
37
38
38
39
39
40
40
41
41
42
43
44
45
45
46
46
47
47
47
48
48
48
49
3
5.1.6 HIPERTEXTO
5.1.7 ORIGENS
5.1.7.1 Psicologia cognitiva
5.2 EVOLUO
5.3 REQUERIMENTOS DE UMA INTERFACE
5.3.1 REQUERIMENTOS DE UMA GUI
5.4 O SOM NA INTERAO
5.4.1 SISTEMAS DE RECONHECIMENTO DE VOZ
5.4.1.1 Sintetizadores da fala
5.5 PERCEPO NA INTERAO
5.5.1 PERCEPO VISUAL
CAPTULO 6 -
O PROJETO DE SOFTWARE
6.1 MODULARIDADE
6.2 FASES DO PROJETO DE SOFTWARE
6.2.1 O PROJETO GLOBAL
6.2.1.1 Diagramas de estrutura
6.3 TCNICAS DE PROJETO
6.3.1 PROJETO ESTRUTURADO
6.3.1.1 Mtodo do projeto estruturado
6.3.2 PROJETO DETALHADO
CAPTULO 7 SOFTWARE
49
49
50
51
53
53
54
54
55
55
55
57
58
58
59
59
60
61
61
64
GERENCIAMENTO E PLANEJAMENTO DE PROJETOS DE

66
7.1 INTRODUO
7.2 FUNDAMENTOS DOS PROJETOS
7.2.1 COMO CONDUZIR UM PROJETO DE SOFTWARE?
7.2.2 COMO INICIAR UM PROJETO DE SOFTWARE?
7.2.3 O QUE CONSIDERAR NO PLANEJAMENTO DE PROJETO DE SOFTWARE?
7.2.4 OS ASPECTOS COMUNS QUE DEVEM SER CONSIDERADOS NAS TCNICAS
ADMINISTRATIVAS:
7.2.5 PREVISO DE RISCOS
7.2.6 DETERMINAO DOS PRAZOS
7.2.7 MONITORAO E CONTROLE
7.3 MEDIDAS DE SOFTWARE

7.3.1 MTRICAS ORIENTADAS AO TAMANHO.
7.3.2 MTRICAS ORIENTADAS FUNO.
7.3.3 MTRICAS DE QUALIDADE
7.3.4 FATORES QUE INFLUENCIAM A PRODUTIVIDADE DO SOFTWARE
7.4 O PLANEJAMENTO DE SOFTWARE
7.4.1 PORQUE PLANIFICAR?
7.4.2 QUANDO PLANIFICAR?
7.4.3 FATORES QUE AFETAM A PRECISO E A EFICCIA DAS ESTIMAES
66
66
67
68
68
69
69
70
70
70
73
73
74
75
76
76
76
76
4
7.4.4 UMA GUIA PARA A PLANIFICAO

7.4.4.1 Escopo do software
7.4.5 ESTIMAO DE RECURSOS
CAPTULO 8 -
A REUTILIZAO DE SOFTWARE
8.1 CONCEITOS BSICOS

8.1.1 PROBLEMAS DO DESENVOLVIMENTO DE SOFTWARE
8.1.2 QUALIDADE E PRODUTIVIDADE ATRAVS DA REUTILIZAO
8.1.3 PROBLEMAS ATUAIS DA REUTILIZAO
8.1.4 O DESENVOLVIMENTO ORIENTADO A OBJETOS E A REUTILIZAO
8.1.5 EFETIVIDADE DA RECUPERAO DE SOFTWARE
8.1.6 CUSTO DA CLASSIFICAO DE SOFTWARE
8.1.7 LINGUAGEM NATURAL PARA CONSULTAS E CLASSIFICAO
8.1.8 REUSABILIDADE
8.1.9 REUTILIZAO VS. MIGRAO
8.1.10 ALGUMAS DEFINIES
8.1.11 QUE REUTILIZAR?
8.1.12 ARTEFATOS REUTILIZVEIS
8.1.13 TCNICAS
8.1.14 ALCANCE
8.1.15 MODALIDADES
8.2 EVOLUO
8.2.1 EVOLUO NA PRTICA DA REUTILIZAO
8.3 O DESENVOLVIMENTO DE SOFTWARE BASEADO NA REUTILIZAO
8.3.1 DESENVOLVIMENTO PARA REUTILIZAO
8.3.2 QUALIFICAO E GENERALIZAO
8.3.2.1 Classificao
8.3.2.2 Evoluo dos repositrios
8.3.3 DESENVOLVIMENTO COM REUTILIZAO
8.3.3.1 Recuperao
x vnculos hipertexto ou hipermdia
8.3.3.2 Recuperao
8.3.3.3 Adaptao
8.3.3.4 Composio
8.4 ABSTRAES DE SOFTWARE PARA A REUTILIZAO
8.4.1 QUE UMA ABSTRAO DE SOFTWARE?
8.4.2 PARTES DE UMA ABSTRAO
8.5 EFETIVIDADE DAS TCNICAS DE REUTILIZAO
8.5.1 CRITRIOS PARA MEDIR A EFETIVIDADE
8.5.1.1 Distancia cognitiva
8.5.2 ANALISE DE EFETIVIDADE DAS TCNICAS DE REUTILIZAO
8.5.2.1 Linguagens de alto nvel
8.5.2.2 Reutilizao informal de cdigo e projeto
8.5.2.3 Componentes de cdigo
8.5.2.4 Paradigma de orientao a objetos
76
77
77
79
79
79
79
80
80
80
81
81
82
82
82
83
83
83
83
84
84
84
85
85
86
86
87
87
87
88
88
88
88
89
89
90
91
91
91
92
92
93
93
94
5
8.5.2.5
8.5.2.6
8.5.2.7
8.5.2.8
8.5.2.9
Esquemas de software
Geradores de aplicaes
Linguagens de muito alto nvel (VHLL)
Sistemas de transformao
Arquiteturas
96
97
98
99
100
Captulo 1 -
Introduo Engenharia de Software
A Engenharia de software a disciplina que estuda tcnicas para o

desenvolvimento e manuteno de software de baixo custo; confivel; de fcil
manuteno.
Surge como resposta crise de software.
Estas tcnicas tratam ao software como um produto de Engenharia que requer
planejamento, anlise, projeto, implementao, prova e manuteno.
1.1 Algumas definies

O estabelecimento e uso de princpios de Engenharia robustos, orientados a
obter de forma econmica software confavel e que funcione eficientemente sobre
mquinas reais (Fritz Bauer, 1969)
Disciplina tecnolgica e administrativa dedicada a produo sistemtica de
produtos de programao, que so desenvolvidos e modificados a tempo e dentro
de um oramento definido (R Fairley, 1985)
1.2 Objetivos da Engenharia de Software
Incrementar a produtividade no desenvolvimento e manuteno dos SC
Melhorar a qualidade
Diminuir os custos de desenvolvimento e manuteno
1.3 A importncia do software

O software tm superado ao hardware como elemento chave do sucesso de
empresas, produtos e sistemas. A suficincia e oportunidade da informao dada
pelo software diferencia uma empresa de seus competidores.
Nas dcadas de 1950-1980 o principal problema era desenvolver hardware de
forma a reduzir o custo de processamento e armazenamento de dados
Desde os 80, os avanos em microelectrnica permitiram reduzir os custos de
hardware e proporcionar maior potncia de clculo.
Hoje, os problemas esto centrados em reduzir custos de desenvolvimento e

manuteno e melhorar a qualidade do software.
1.4 O qu o software?
SOFTWARE = PROGRAMAS (instrues) + ESTRUCTURAS DE DATOS +
ESPECIFICACOES + MANUAIS DE USO
As instrues, quando se executam, subministram o comportamento esperado do
sistema. As estruturas de dados armazenam a informao que os programas
manipulam. Os manuais descrevem a operao e o uso dos programas. As
especificaes descrevem os software nas diferentes fases de desenvolvimento
(anlise, projeto e implementao).
O software composto por dos tipos de componentes: componentes no
executveis, como especificaes de requerimentos e de projeto e componentes
executveis, como o cdigo de um programa.
1.5 Sistema de computao

Um sistemas de computao um conjunto de elementos organizados para levar
a cabo algum mtodo, procedimento ou controle atravs do processamento da
informao.
1.5.1
Elementos de um SC
Os elementos de um sistemas de computao so:
Software: Produtos do ciclo de desenvolvimento utilizados para realizar o

mtodo, procedimento ou controle requerido (especificaes de requisitos,
especificaes de projeto, programas, casos de prova)
Hardware: Dispositivos eletrnicos que proporcionam a capacidade de

processamento para a execuo dos mtodos (processador, memria
RAM, disco rgido)
Pessoas: Indivduos (Usurios, Clientes, Operadores de hardware e

software)
Bases de dados: Conjunto grande e organizado de informao ao qual se

acessa pelo software e que uma parte integral do funcionamento do
sistema
Documentao: Manuais e outra informao que explica o uso e a

operao do sistema
Procedimentos: Os passos que definem o uso especfico de cada elemento

do sistema
1.5.2
Evoluo dos sistemas de computao
Podemos distinguir trs eras em relao evoluo dos sistemas informticos:

(1950-1965) Primeira era
Caraterizada pelos sistemas batch
A maior parte do hardware se dedicava execuo de um nico programa por
vez.
O desenvolvimento do software era um processo artesanal. O software era
projetado a medida para cada problema e tinha uma distribuio relativamente
pequena: para cada problema e para cada cliente.
O desenvolvimento dos sistemas estava personalizado. A mesma pessoa
programava, executava, depurava e mantenha. O projeto era um processo
implcito, executado na cabea de algum. Como documentao no existia e a
mobilidade no trabalho baixa se esperava que a pessoa estaria l quando se
encontrara algum erro
(1965-1975) Segunda era
Surge o uso de software como produto, Aparecem as primeiras software houses
e comea a se organizar a industria do software.
Comea a distribuio de programas a mltiplas clientes
Nesta poca comearam problemas com a manuteno do software devido
correes por falhas o por cmbios nos requerimentos do usurio.
Como conseqncia do desenvolvimento artesanal personalizado surgem grandes
dificuldades para manuteno corretiva e evolutiva e o esforo dedicado
manuteno do software comeou a absorver recursos de forma alarmante.
Os sistemas informticos de esta era foram sistemas multiusuarios, aparece a
multiprogramaao, o seja vrios programas podem executar-se simultaneamente na
mesma mquina.Por outro lado, o desenvolvimento personalizado de grande parte do software
fazia com que muitos programas fossam impossveis de serem mantidos.
Isto deu origem crise do software.A diminuio de custos dos dispositivos de armazenamento em disco permitiu
desenvolver SGDB (Sistemas de gerncia de bases de dados)
Comeam a surgir novas modalidades de interao homem-computador, como as
interfaces de comando
Como conseqncia disso, as aplicaes de software se tornam cada vez mais
sofisticadas
Nesta era tambm comea a se desenvolver a capacidade de comunicao de
dados. Aparecem os sistemas de teleprocessamento. Estes sistemas possuem 3
funes combinadas:
processamento de software aplicativo
processamento das BD
processamento da rede de comunicao (controle das interfaces entre os

componentes do ST e da transferencia da informao)
O crescimento nos sistemas de teleprocessamento comea a provocar sobrecarga

do processador central por incremento funcional. Surgem os processadores de
comunicaes e de BD independentes.
(75-90) Terceira era
Era caraterizada pelo grande desenvolvimento das redes de comunicao de
dados. Surgem as redes de comunicao locais e de longa distancia
A demanda de acesso instantneo a os dados cada vez maior.
Surgem os sistemas distribudos onde vrios computadoras executam funciones
concorrentemente, se comunicam entre si e compartem recursos (memria,
dispositivos de E/S)
Os avanos na Microeletronica levam ao desenvolvimento do computadoras
pessoais (PC), onde se verifica uma grande reduo da relao preo/capacidade
de processamento.
A diminuio dos custos do hardware faz aumentar a demanda de software em
novas reas
Se produz um crescimento das software houses e da distribuio no nmero de
seus produtos
Os sistemas informticos se tornam cada vez mais complexos.
10
So propostos mtodos e ferramentas avanadas para o desenvolvimento de

software.
Nesta era, a crise de software se mantm
Desde 90 Quarta era, atual
Caraterizada por:
incremento exponencial no desenvolvimento de sistemas Web
crescimento na complexidade das aplicaes
sistemas distribudos
sistemas de controle
Reutilizao e desenvolvimento orientado a objetos
objeto como abstrao de software
Novas reas de aplicao:

aplicaes domsticas
Tendncias: sistemas baseados em conhecimento, agente como abstrao

de software, automao do processo de desenvolvimento de software
1.5.3
educao,
comercio
eletrnico,
jogos,
Evoluo nas modalidades de processamento da informao
Os sistemas de processamento da informao tem evolucionado de sistemas de

processamento centralizado sistemas de processamento distribudo.
1.5.3.1
Processamento centralizado
Nesta modalidade de processamento, vrias mquinas com capacidade de

processamento so reunidas em um nico local
Os fatores contribuintes para esta modalidade de processamento tem sido:
Centralizao das atividades num nico local para otimizar (codificao,

entrada, processamento e sada)
Primeiros SGBD - Dados centralizados
Economia de escala: Concentrao justificada pela necessidade de dividir

custos entre mltiplas aplicaes (instalao, operao, manuteno)
11
Importncia do CPD
Centralizao reforava a influencia do CPD na empresa
Administradores do CPD
administradores da informao da empresa
centros de poder
O processamento centralizado apresentava os seguintes problemas:
Software de controle - maior parte do tempo de processamento
Congestionamento do software aplicativo
Interrupo no processamento - paralisao de atividades
Saturao de determinada tecnologia
Saturao de recursos do sistema centralizado por incremento na

complexidade das aplicaes multiusurio
Na medida que o sistema utilizado por mais usurios, aumenta sua

saturao
Novas Tecnologias substituem Tecnologias que j alcanaram seu

ponto de saturao
As limitaes do processamento centralizado foram a justificativa econmica para

a distribuio:
micros, minicomputadores e mainframes
distinguir de descentralizao
processamento e dados localizados em diferentes centros sem

integrao
redundncia de atividades
aumento dos custos
1.5.3.2
Processamento distribudo
O principal fator contribuinte para

desenvolvimento das telecomunicaes:
processamento
distribudo
foi
12
Substituio de
teleprocessamento
Usurio - funes de entrada de dados e consulta de dados armazenados
terminais locais ligadas diretamente ao computador central
terminais remotas ligadas atravs de redes locais ou de longa distancia
transferencia
fsica
de
dados
(papel)
por
Os componentes de um sistema distribudo so:
Processamento - Existem vrios processadores
Dados - compartilhados em diferentes ns com capacidade de processamento
Controle - componente fundamental, mais complexo que nos sistemas

centralizados; Faz a coordenao de diferentes processos a travs da troca de
mensagens
Os seguintes critrios de distribuio so geralmente utilizados:
reas geogrficas
Distribuio geogrfica dos dados
Dados distribudos e agrupados segundo freqncias de acesso de cada

rea
Minimizao do trfego inter-ns
Grupos funcionais
Assinao de capacidade de processamento por departamento funcional
Funes do PD
Servidores especializados( De e-mail, De impresso,Com software

especializado)
1.6 Elementos da Engenharia de Software
Modelos de desenvolvimento
Ciclo de vida
Mtodos e tcnicas - Indicam como construir o software (Estruturadas,

orientadas a objetos, baseadas em agentes)
13
Procedimentos - definem a seqncia de aplicao dos mtodos
Metodologias - conjunto sistematizado de tcnicas para a ser aplicado em uma,

varias ou todas as fases do ciclo de desenvolvimento de um produto de
software
Ferramentas - Aplicaes de software que do suporte automtico ou semiautomtico a mtodos ou metodologias para o desenvolvimento de software
Ambientes de desenvolvimento
1.7 Deterioro do hardware vs software

O software se deteriora de forma diferente ao hardware. O hardware exibe poucas
falhas ao comeo de sua vida e essas falhas so geralmente atribuveis a defeitos
de projeto e fabricao (mortalidade infantil). Quando se corrigem os defeitos, as
falhas caem a sua nvel ms baixo e permanecem estacionrios durante certo
perodo de tempo. Conforme passa o tempo falhas voltam a apresentar-se a
medida que os componentes de hardware sofrem os efeitos cumulativos de
sujeira, vibrao, uso, etc .(Figura 1).
mortalidade infantil
deterioro
Figura 1- Deterioro do hardware vs Software - falhas do hardware
O software no susceptvel aos males do entorno como o hardware. Defeitos

no descobertos faro que falhe durante as primeiras etapas de sua vida. Uma
vez corrigidos, supondo que no se introduzem novos errores, a curva se
aplanaria
O software se deteriora devido cmbios (manuteno) atravs dos quais se
introduzam novos erros (defeitos). A curva de falhas tem picos. Antes que a curva
volte ao estado estacionrio original, se solicita outro cambio, fazendo que de
novo se crie outro pico e lentamente, o software vai-se deteriorando devido a os
cmbios ( Figura 2).
14
Curva real
cambio
Curva idealizada
Figura 2 - Deterioro do hardware vs Software - falhas do software
1.8 Tipos de software
Software de sistemas
Aplicao de software - Executa tarefas especficas num domnio de problema

Ex. Folhas de pagamento, Controle de estoque
Software de tempo real - mede, analisa e/o controla sucessos do mundo real
na medida que ocorrem. Distinguir entre software de tempo real e software
interativo. Um sistema de tempo real deve responder dentro de limites estritos
de tempo. O tempo de resposta em um sistema interativo pode ser superado
sem que se produza nenhum desastre.
Software de gesto o sistemas de informao: aplicaes para o processo de

informao comercia e administrativa Constituem a maior rea de aplicao do
software
Software cientfico: baseado na utilizao de algoritmos de clculo e anlise

numrico (projeto assistido por computador, simulao de sistemas)
Software de PC: Processadores de palavra, planilhas eletrnicas, grficos,

jogos, aplicaes educativas, financeiras e comerciais
Software de Web - Agentes e robots buscadores, aplicaes de comercio

eletrnico, educativas, jogos, etc
Software de IA - aplicaes baseadas no conhecimento, incorporam

mecanismos de raciocnio, cooperam e aprendem (ex.agentes inteligentes,
sistemas expertos) Fazem uso de algoritmos no numricos (processamento
simblico) para a resoluo de problemas complexos Reconhecimento de voz,
processamento de linguagem natural, jogos, prova de teoremas)
15
1.9 A crise do software

Carateriza os problemas de desenvolvimento e manuteno do software:
Demanda crescente de software
Problemas na manuteno de software
falta de documentao
no aplicao de adequadas metodologias de desenvolvimento
quantidade e qualidade
desproporo entre os custos do hardware e o software
custo do software atualmente o elemento principal na distribuio de

custos de um sistema informtico
crescimento em complexidade e domnios de aplicao
planejamento e estimao de custos geralmente muito pouco precisa
Geralmente os custos estimados so superados em ordenes de magnitude

(de meses a anos)
formao de pessoal qualificado
falta de metodologias e ferramentas adequadas as novas aplicaes
a comunicao entre o que desenvolve o software e o usurio no ,

adequada
os requisitos do cliente so expressados de maneira vaga o pouco precisa
freqentemente o cliente fica insatisfeito com o sistema final
qualidade do software questionvel
recentemente tem comeado a praticar-se a prova sistemtica e completa

do software
cmbios muito rpidos nos ambientes dos SC
Qual a soluo?
Dar um enfoque de Engenharia ao desenvolvimento de software
16
Melhorar as tcnicas e ferramentas existentes
Promover o desenvolvimento para e com reutilizao
1.10 Problemas do desenvolvimento de software
Crescimento da demanda de software
Novos domnios de aplicao
Complexidade das aplicaes
Custo da manuteno de software
Confiabilidade do software
Mudanas nos requisitos das aplicaes
Problemas na aquisio e especificao de requisitos
A crise de software se mantm. Avanos na ES provocam maior demanda em

reas mais complexas.
17
Captulo 2 - Modelos de Desenvolvimento

Um modelo de desenvolvimento estabelece as fases do ciclo de vida que
atravessa um produto de software durante seu desenvolvimento e manuteno e
os passos donde se aplicaro tcnicas, ferramentas e procedimentos
A escolha de um paradigma depende de:
a natureza da aplicao
os mtodos e ferramentas a utilizar
os controles e entregas requeridos
Enfatizam as primeiras fases do ciclo de desenvolvimento
requisito
projeto
mais produtivo e efetivo fazer mudanas nas especificaes de requisitos e
projeto que mudar e provar o cdigo fonte
Os principais modelos de ciclo de vida so:
Ciclo de vida clssico (modelo em cascata)
Paradigma da prototipao
Ciclo de vida em espiral
Paradigma dos linguagens de quarta gerao
Combinao de paradigmas
2.1 O ciclo de vida em cascata

2.1.1
Anlise u Engenharia de sistemas
Definio dos requerimentos de todos os elementos do sistema
hardware
18
software
pessoas
instalaes
Atribuio de parte de esses requerimentos ao software
2.1.2
Anlise de requerimentos do software
Compreenso do domnio da aplicao e especificao do problema do mundo

real
Compreenso e especificao de
Funciones requeridas
Rendimentos
Interfaces
2.1.3
Produto: especificao de requisitos
Projeto
soluo computacional aos requerimentos estabelecidos

os requisitos so representados numa linguagem do mundo computacional
Produtos
A arquitetura do software (projeto global)
Estruturas de dados (projeto detalhado)
Detalhe dos procedimentos (projeto detalhado)
2.1.4
Codificao
representaes do projeto so traduzidas a um linguagem artificial (linguagem de

programa convencional o de 4ta Gerao)
o resultado um conjunto de instrues executveis
Produto
19
um o mais programas
2.1.5
Prova
software provado para detectar os defeitos que possam existir na

implementao
Prova se enfoca em
A lgica interna dos programas
As funciones externas atribuindo que para determinadas entradas se produziro
os resultados requeridos
Produto
casos de prova (entradas e resultados esperados)
2.1.6
Integrao
os programas provados so integrados para compor o software aplicativo ou de

sistema
Produto: aplicao de software
2.1.7
Manuteno
software sofre cmbios depois de que entregue ao cliente

cmbios ocorrem por:
erros do software
Cambio no entorno externo do software
Requerimentos de novas funciones o rendimento
As fases e produtos da manuteno so as mesmas que para o desenvolvimento
20
Engenharia de
sistemas
Engenharia de
requisitos
Projeto
Codificao
Integrao
e prova
Manuteno
Figura 3 - Ciclo de vida clssico ("cascata")
2.2 Crticas ao ciclo de vida em cascata

os projetos reais raramente seguem o fluxo seqencial (e top-down)que prope o
modelo
combinao de top-down e bottom-up
sempre ocorrem interaes e a vezes existem problemas na aplicao do
paradigma
difcil tanto para o cliente como para o analista estabelecer ao principio,
explicitamente, todos os requerimentos
ciclo de vida clssico tem dificultadas em expressar possveis incertezas
muita pacincia do cliente
a verso funcionando da aplicao somente estar disponvel nas etapas finais
do desenvolvimento do projeto
presena de erros nos requerimentos estabelecidos, nas etapas finais, pode ser
uma situao grave
erros durante a especificao de requerimentos o cmbios nos requerimentos
durante o desenvolvimento
21
produto gerado no atender adequadamente as necessidades do cliente
2.3 Contribuies do ciclo de vida em cascata

Enfoque sistemtico e seqencial do desenvolvimento de software
Desenvolvimento dividido em fases bem definidas
As atividades so executadas de forma iterativa e o refinamento permitido
2.4 Paradigma da prototipao

prottipo
verso do SC que contm as caractersticas bsicas do sistema final
pode utilizar-se somente para fines de experimentao o pode evolucionar
a travs de sucessivos prottipos que incrementam a funcionalidade do
sistema
Engenharia de
requisitos
PROTOTIPO
CONSTRUIDO
experimental
sistema final
Projeto
rpido
Construo
do prottipo
Usar e avaliar
o prottipo
Prottipo
satisfatorio?
NAO
Figura 4 - Ciclo de vida baseado na prototipao
22
2.4.1
Quando aplica-lho
Quando os requerimentos da aplicao mudam rapidamente, porque o entorno da

aplicao muda
Quando os requerimentos do usurio no so bem entendidos o no podem ser
totalmente definidos em uma primeira etapa
Como mtodo para captar o especificar claramente os requerimentos
o prottipo a prpria especificao de requisitos
Quando existem problemas de comunicao entre o cliente e o analista
prottipo possibilita a comunicao e permite medir a satisfao do cliente com
relao ao produto
Para experimentar a interface com o usurio
Para avaliar experimentalmente funciones o eficincia de um algoritmo
2.4.2
Vantagens da prototipao
prottipo real: da ao usurio e ao analista uma forma tangvel de compreenso

e avaliao do problema permitindo uma retroalimentao de necessidades e
requisitos
comum a usurios e analistas: oferece um ponto de referencia comum a
usurios e analistas para a identificao de problemas e necessidadesestimula a participao do usurio no projeto: melhora a comunicao
2.4.3
Problemas da prototipao
Na administrao e controle do projeto

dificuldade para planificar, estimar custos e controlar os prottipos
Pode gerar expectativas difceis de atingir
Ex.. O usurio pode pressionar para liberar o prottipo como sistema final
23
2.5 Tcnicas da quarta gerao

Se orientam habilidade de especificar software em linguagem de alto nvel
(prximo ao linguagem natural)
A partir da especificao a ferramenta gera automaticamente o cdigo fonte
Disponvel somente para domnio de aplicaes especficas
A curva de aprendizagem alta
Problemas de eficincia por grandes quantidades de dados
Redues importantes no tempo de desenvolvimento
Melhora na produtividade
A manuteno realizada na prpria especificao
Engenharia de
requisitos
Estrategia
de projeto
Implementao
usando L4G
Aplicao
Figura 5 - Ciclo de vida para L4G
2.6 Modelo em espiral

Integra a prototipacao com o modelo em cascata
Anlise de requisitos, projeto e codificao so executados ciclicamente
Exemplifica a programao evolucionaria
24
Figura 6 - Ciclo de vida em espiral
2.7 Mtodos, metodologias e ferramentas de desenvolvimento

Desenvolvimento orientado a objetos
Ferramentas CASE
Desenvolvimento formal de software
Desenvolvimento baseado em Agentes
Engenharia de Software baseada na Reutilizao
Desenvolvimento PARA reutilizao
Desenvolvimento COM reutilizao
2.8 Engenharia de software baseada na reutilizao

DOO
Reuso em caixa preta (ex.. Instanciao)
Reuso em caixa branca, por especializao (ex. Herana)
Reuso de projetos (padres de projeto e arquiteturas)
25
Reuso de componentes de cdigo
2.9 Ferramentas CASE

Automatizam partes do processo de desenvolvimento
gerao automtica de cdigo
linguagens de quarta gerao
modelagem de requisitos (ex. DFD)
especificao e verificao formal de software (ex. Redes de Petri)
Groupware
2.10 Groupware
Trabalho em grupo no desenvolvimento de software assistido por computador
Necessrio para o desenvolvimento de grandes aplicaes
Ferramentas
tormenta de idias (brainstorming)
planificao
resoluo de conflitos
inspeo de software
2.11 Viso genrica do processo de desenvolvimento do software

trs fases genricas, independentemente do paradigma escolhido
26
Definio
Desenvolvimento
Manuteno
Figura 7 - Viso genrica do processo de desenvolvimento de software
2.11.1 Definio
O qu
Qu informao se processa
Qu funo e rendimento se deseja
Qu qual ser a interface com o usurio
Qu critrios de avaliao se utilizaro para provar a correo do sistema
Fases
Anlise do sistema
Planejamento
Anlise de requerimentos
2.11.2 Desenvolvimento
O como
Como se projetaro as estruturas de dados
Como se projetara a arquitetura do software
Como se detalham os procedimentos
Fases
27
projeto
Codificao
Prova
2.11.3 Manuteno
Cmbios que necessrios introduzir ao sistema por:
manuteno corretiva: correo de defeitos do software
migrao: adaptao por cmbios do entorno do sistema (por ex. CPU,

sistemas operativos)
manuteno evolutiva: incorpora novas funciones
28
Captulo 3 - Engenharia de sistemas

A partir dos objetivos e restries definidos pelo usurio so detectadas e
analisadas as funes que se desejam para o sistema de computao. As funes
so atribudas a um ou mais elementos do sistema.
Nesta fase desenvolvida uma especificao das funes, do rendimento, das
interfaces e das restries do projeto e da estrutura da informao.
3.1 Tarefas da Engenharia de Sistemas

As principais tarefas da Anlise de Sistemas so:
Identificar as necessidades do cliente e definir objetivos;
Avaliar a viabilidade do sistema
Atribuir funes ao software, ao hardware, s pessoas, s bases de dados e a

outros elementos do sistema.
Estabelecer restries de custo e tempo
Criar uma especificao do sistema que seja a base para tudo o trabalho
posterior
3.1.1
Identificao das necessidades do cliente e definio de

objetivos
Esta atividade geralmente conduzida atravs da realizao de entrevistas.

importante distinguir entre o que o cliente realmente necessita e o que o cliente
quer.
Na definio de objetivos dever considerar-se:
Que informao vai produzir o sistema;
Que informao vai se subministrar ao sistema;
Quais as funes e rendimento requerido;
Quais os requisitos de segurana a serem considerados
Nesta fase tambm preciso avaliar:

29
A tecnologia disponvel;
As restries de custos e tempo de desenvolvimento
O mercado e a competitividade (mercado potencial; produtos da

competncia)
Aspetos de confiabilidade e qualidade desejada no produto a ser

desenvolvido
3.1.2
Estudo de viabilidade
Todos os projetos so realizveis porm dados recursos ilimitados e tempo

infinito. O estudo de viabilidade determina a realizao ou discontinuao do
projeto. As limitaes podem estar dadas por recursos ou tempo disponveis.
Os estudos de viabilidade incluem:
Econmica: Avaliao do custo de desenvolvimento em relao ao beneficio

que oferecera o sistema
Operativa: Avaliao do impacto da introduo do sistema na organizao
Tcnica: Avaliao da existncia de tecnologia e recursos humanos para a

construo do sistema
Legal: Determinar possveis infraes que possam surgir na construo do

sistema
Viabilidade econmica (Anlise de custo-beneficio)

Beneficios
Tarefas de clculo e impresso
Manuteno da informao
Consulta da informao
Anlise e simulao
Custos
Compra e aluguel de equipamentos
Acondicionamento de instalaes
30
Capital
Custos relativos ao desenvolvimento
Custos
Benefcios
Ponto de igualdade
Custos
Anos
Perodo de amortizao
Figura 8 - Anlise de custo-beneficio
Viabilidade operativa
Avaliao do impacto da introduo do sistema na organizao
Viabilidade tcnica
Avaliao da existncia de tecnologia e recursos humanos para a cosntruo do
sistema
Viabilidade legal
Determinar possveis infraes que possam surgir com a construo do sistema
Alternativas
Avaliao de possveis alternativas para o desenvolvimento do sistema
31
Captulo 4 - Engenharia de requisitos

4.1 Principais conceitos
Os requisitos do sistema definem o que solicitado ao sistema fazer e com quais
limitaes ele requisitado a operar. Por exemplo:
O sistema deve manter registro de todos os materiais da biblioteca

incluindo livros, sries, jornais e revistas, fitas de vdeo e udio, relatrios,
colees de transparncias, discos de computadores, e CD-ROMs.
O sistema deve permitir os usurios pesquisar atravs do ttulo, autor ou

ISBN.
A interface de usurio do sistema deve ser implementada usando um

browser de WWW
O sistema deve suportar pelo menos 20 transaes por segundo.
As facilidades do sistema que esto disponveis para o pblico devem ser

demonstradas em 10 minutes ou menos.
4.2 Tipos de requisitos
Requisitos funcionais que definem parte da funcionalidade do sistema.
Requisitos de implementao que dizem como o sistema deve ser

implementado.
Requisitos de performance que especificam a performance mnima

aceitvel do sistema.
Requisitos de usabilidade que especificam o tempo mximo o aceitvel

para demonstrar o uso do sistema.
Requisitos No Funcionais que dizem respeito a restries, aspectos de

desempenho, interfaces com o usurio, confiabilidade, segurana,
manutenabilidade, portabilidade
Requisitos Organizacionais que dizem respeito s metas da empresa,

polticas estratgicas adotadas, empregados da empresa com seus
respectivos objetivos; enfim toda a estrutura da organizao.
32
4.3 Problemas dos Requisitos
Os requisitos no refletirem as reais necessidades dos clientes do sistema.
Os requisitos serem inconsistentes e/ou incompletos.
O custo alto para se fazer mudanas de requisitos depois de terem sido

concordados.
Existirem mal entendidos entre clientes (que apresentam os requisitos do

sistema) e os engenheiros de software que desenvolvem ou mantm o
sistema.
4.4 E.R. Motivao
33
Alguns aspectos jurdicos:
o documento de requisitos um acordo contratual entre clientes e

fornecedores
os desenvolvedores de software tem obrigao de inquirir os requisitos dos

seus clientes e informar seus usurios acerca da soluo proposta (um
manual de usurios no suficiente!)
4.5 Questes mais freqentemente perguntadas sobre requisitos

(FAQS)
O que so requisitos?
Uma descrio de um servio ou de uma limitao
O que a engenharia de requisitos?

O processo envolvido no desenvolvimento de requisitos de um sistema
Quanto custa a engenharia de requisitos?

Cerca de 15% dos custos do desenvolvimento do sistema.
O que o processo de engenharia de requisitos?

Um conjunto estruturado de atividades envolvidas no desenvolvimento dos requisitos do
sistema
O que acontece quando os requisitos esto errados?

34
Os sistema atrasam, ficam no confiveis e no satisfazem as necessidades dos clientes.
Existe um processo de engenharia de requisitos ideal?

No - os processos precisam ser adaptados as necessidades organizacionais.
O que um documento de requisitos?

Um descrio formal dos requisitos do sistema.
O que so stakeholders do sistema?

Qualquer pessoa afetada de alguma forma pelo sistema.
Qual o relacionamento entre requisitos e projeto?
Requisitos e projeto esto interligados. Idealmente eles deveriam ser separados, mas na
prtica isto impossvel.
O que gerenciamento dos requisitos?

O processo envolvido no gerenciamentovdas mudanas dos requisitos
4.6 A engenharia de requisitos e as outras fases do ciclo de

desenvolvimento
ENGENHARIA
ENGENHARIA PROJETO
DE
DE
SISTEMAS
REQUISITOS
Refinamento das
atribuies realizadas
ao software
Representao da informao
e funes requeridas
35
Engenharia de
sistemas
Especificao
de requisitos
Engenharia de
requisitos
Projeto
Codificao
Manuteno
Integrao
e prova
Figura 9 - A Engenharia de Requisitos e o processo de desenvolvimento de
software
4.7 Fundamentos da anlise de requisitos

Os requisitos do software devem ser expressos de forma completa e consistente
um processo de
Descobrimento e
Refinamento
Participao ativa de
Analista
Usurio/cliente
Dificuldades na comunicao
M interpretao
Falta de informao
36
4.8 Tarefas da anlise de requisitos
Reconhecimento do problema
Compreenso e representao de domnio
Especificao dos requisitos
Reviso
4.8.1
Reconhecimento do problema
CLIENTE/USURIO
Consulta
Pergunta ANALISTA
Especifica
Projeta em
alto nvel
EQUIPE
DE
DESENVOLVIMENTO
Constri
Elabora
Consulta
Consulta
Modifica
Plano do projeto
Prottipo
Especificao de requisitos
Figura 10 - Canais de comunicao
Caratersticas ideais de um analista:

o Capacidade de abstrao
o Habilidade para compreender e organizar logicamente conceitos abstratos
o sintetizar solues a partir deles
o Habilidade para captura conceitos de fonte conflituosa ou confusas
o Habilidade de comunicao verbal e escrita
o Conhecimento dos modelos de desenvolvimento
37
4.8.2
Compreenso e representao de domnio

o funes
o fluxo de informao
o interface usurio
Deve compreender-se e representar-se o domnio da aplicao

o domnio da informao
o domnio funcional
O problema deve decompor-se de forma que os detalhes se descubram de forma
progressiva
Devem especificar-se as representaes lgicas e fsicas
4.8.2.1
O domnio da informao
o Fluxo
o Contedo
o Estrutura
4.8.2.1.1 Fluxo da informao
Armazm
de dados
Dados
de
entrada
Transformao 1
Dados
intermedirios
Transformao 2
Dados
de
sada
Figura 11 -Fluxo da informao
4.8.2.1.2 Contedo da informao

REGISTRO EMPREGADO
38
NMERO
NOME
ENDEREO
SALRIO
4.8.2.1.3 Estrutura da informao
Estudante
Disciplina
4.9 Princpios da anlise de requisitos
Deve compreender-se e representar-se o domnio da aplicao

o domnio da informao
o domnio funcional
O problema deve decompor-se de forma que os detalhes se descubram de

forma progressiva
Devem especificar-se as representaes lgicas e fsicas
4.9.1
Decomposio do problema
SISTEMA DE BIBLIOTECA
Detalhamento
COMPRAR
EMPRESTAR
VERIFICAR
DISPONIBILIDADE
RESERVAR
REGISTRAR
EMPRSTIMO
Decomposio
39
4.9.2
Vises lgicas e fsicas dos requisitos
LOGICA
FISICA
Uma primeira aproximao

- Funes a realizar
- Informao a processar a como se implementaram
funes e estruturas de
Independente de detalhes informao
de implementao
Atribuio a elementos do SC
4.10 A especificao de requisitos

Referncia a Figura 9
Contrato
cliente-equipe de desenvolvimento
usurio-equipe de desenvolvimento
Abstrao (modelo)
situao real o imaginada
documento (descries grficas e ling.natural)
prottipo (especificao executvel)
representao formal (especificao executvel, validao)
Mtodos e ferramentas
L4G, geradores de aplicaes
Reuso de componentes
Programao automtica
A especificao (documento) de requisitos:
40
um documento formal usado para comunicar os requisitos aos clientes,

engenheiros e gerentes.
O documento de requisitos descreve:
Os servios e funes que o sistema deve prover;
As limitaes sobre as quais o sistema deve operar;
Propriedades gerais do sistema, isto limitaes nas propriedades emergentes;
Definies de outros sistemas com o qual o sistema deve se integrar.
4.10.1 Propriedades emergentes

So propriedades do sistema como um todo que somente emergem quando todos
os sub-sistemas estiverem integrados.
Exemplos de propriedades emergentes
Confiabilidade
Manutenabilidade
Desempenho (Performance)
Usabilidade
Segurana
O documento de requisitos tambm descreve:
Informaes sobre o domnio da aplicao do sistema; ex.: como calcular um certo
tipo de valor
Limitaes nos processos usados para desenvolver o sistema;
Descries sobre o hardware no qual o sistema ir executar.
Glossrio que explica a terminologia usada
4.10.2 Usurios do documento de requisitos

Clientes do Sistema
Especificam os requisitos e os lem para checar se eles satisfazem suas
necessidades.
41
Gerentes de Projeto
Usam os documentos de requisitos para planejarem uma proposta para o sistema
e o processo de desenvolvimento do sistema.
Engenheiros de Sistema
Usam os requisitos para entenderem o sistema em construo.
Engenheiros de teste do sistema
Usam os requisitos para desenvolverem testes de validao do sistema.
Engenheiros de manuteno do sistema
Usam os requisitos para entenderem o sistema.
4.10.3 A estrutura do documento de requisitos

Padro IEEE/ANSI 830-1993 uma estrutura para o documento de requisitos
1 Introduo
1.1 Propsito do documento de Requisitos
1.2 Escopo do produto
1.3 Definies, acrnimos e abreviaes
1.4 Referencias
1.5 Resumo do resto do documento
2 Descrio Geral
2.1 Perspectiva do produto
2.2 Funes do produto
2.3 Caractersticas do usurio
2.4 Limitaes gerais
2.5 Suposies e dependncias
3 Requisitos especficos
Cobrem requisitos funcionais, no-funcionais e interface.
4. Apndices
ndice
42
4.10.3.1
Adaptando um padro
O padro do IEEE genrico e pretende ser aplicado em uma variada gama de

documentos de requisitos.
Em geral, nem todas as partes do documento so necessrias para todos os
documentos de requisitos.
Cada organizao dever adaptar o padro de acordo com o tipo de sistema que
desenvolve.
Padro da empresa XYZ
Considere uma companhia (XYZ) que desenvolve equipamentos cientficos.
Prefcio
Define os leitores do documento e descreve a histria das verses, incluindo um explicao da
criao de novas verses e um resumo das mudanas feitas em cada verso.
Introduo
Define o produto no qual o software est embutido, seu uso esperado e apresenta um resumo da
funcionalidade do software de controle.
Glossrio
Define todos os termos tcnicos e abreviaes usadas no documento.
Requisitos gerais do usurio

Define os requisitos do ponto de vista dos usurios do sistema. Isto inclui uma mistura de
linguagem natural e diagramas.
Especificao detalhada de software

Descrio detalhada da funcionalidade esperada do software. Poder incluir detalhes de algoritmos
especficos que devem ser usados na computao.
Especificao de Hardware
Parte opcional que especifica o hardware que o software dever controlar. Poder ser omitido se
uma plataforma padro de instrumento for ser utilizada.
Requisitos de confiabilidade e performance

Este captulo deve descrever os requisitos de confiabilidade e performance esperados do novo
sistema.
Quando apropriado, os seguintes apndices podero ser adicionados:

43
Especificao da interface de Hardware;

Componentes de Software que devero ser reusados na implementao do sistema;
Especificao da estrutura de dados;
Modelos de fluxo de dados do sistema de software;
Modelos detalhados de objetos do sistema de software.

ndice
4.11 Construo de prottipos

1 - Avaliar descrio preliminar do software:
rea de aplicao
complexidade
caratersticas do cliente
caratersticas do projeto
2 - Desenvolver descrio abreviada dos requisitos

3 -Esboar especificao de projeto
4 - Construir, testar e refinar o prottipo
5 - Apresentar prottipo ao cliente (eventualmente modifica-lho)
6 - Repetir passos 4-5 (especificao completa ou sistema final)
44
4.11.1 Paradigma da prototipao
Engenharia de
requisitos
PROTOTIPO
CONSTRUIDO
experimental
sistema final
Projeto
rpido
Construo
do prottipo
Usar e avaliar
o prototipo
(cliente/usuario)
SIM
Prottipo
satisfatorio?
NAO
4.12 Roteiro para a especificao de requisitos

1 - Introduo (descrio dos objetivos do software)
2 - Descrio da informao
a - Representao do fluxo
b- Representao do contedo
c- Representao da estrutura
d - Representao da interface usurio
3 - Descrio funcional
a - Texto explicativo de cada funo
b - Restries/limitaes
c - Requisitos de desempenho
d - Diagramas
45
4 - Critrios de validao (casos de testing)
4.13 Mtodos para a anlise de requisitos

Aplicao sistemtica dos princpios da anlise de requisitos
Mecanismos para a anlise do domnio da informao
Representao grfica
Mecanismos de abstrao, decomposio e refinamento
Representao de vises lgicas e fsicas
4.13.1 Classificao dos mtodos para a anlise de requisitos

Anlise orientado ao fluxo de dados
Anlise orientado s estruturas de dados
Anlise orientado a objetos
46
Captulo 5 -
Interao Humana - Computador
5.1 Conceitos bsicos

A Interao Humana - Computador (HCI) a disciplina que aborda o projeto,
implementao, uso e avaliao de sistemas interativos. De uma forma geral, ela
tambm aborda os problemas associados ao impacto do uso de computadores
nos indivduos, organizaes e na sociedade em geral.
A interao usurio - computador possui hoje as seguintes caractersticas. Os
usurios (informticos e no informticos) possuem diferentes destrezas e
diferentes idades. O tipo de usurio determina o xito de interface em funo do
treinamento, tratamento de erros e adequao a destrezas oferecidas pelo
sistema.
Por outro lado, o crescimento em complexidade das aplicaes tem provocado um
incremento em complexidade ainda maior nas interfaces dessas aplicaes, por
exemplo, de simples interfaces de editores de texto a interfaces de sistemas de
controle de trfego areo.
Uma interface mal projetada afeta:
Usurio (fatiga, estresse, mal-estares fsicos)
Cliente (altos custos treinamento, rpidos e freqentes cmbios de turno)
Projetista (altos custos de manuteno, reaes dos consumidores)
5.1.1
Importncia da HCI
A HCI crtica para o desenvolvimento de aplicaes bem-sucedidas, efetivas e

simples de aprender, permitindo:
diminuio de custos
incremento da produtividade
reduo de falhas (ex. Controle de vos)
47
5.1.2
reas de aplicao
Interfaces orientadas a documentos (ex., edio de texto, planilhas eletrnicas)
Interfaces orientadas s comunicaes (ex., correio eletrnico, telefonia,

teleconferncia)
Ambientes de desenvolvimento
software, CAD/CAM)
Sistemas tutoriais e de ajuda em linha
Sistemas de controle (ex.,

simuladores, jogos de vdeo)
Sistemas embutidos (ex., elevadores, eletrodomsticos)
5.1.3
(ex., ferramentas de desenvolvimento de
controle
de
processos,
realidade
virtual,
Interface usurio
Uma interface o lugar de contato entre pelo menos duas entidades.

Uma interface -usurio se define como o conjunto de objetos, ferramentas,
linguagens e representaes visuais entre uma pessoa e um computador.
Compreende canais de informao que permitem que usurio e computador se
comuniquem
Toda interao implica uma relao emisor-receptor onde cada uma das partes
tem uma imagem da outra segundo a qual se estruturam e interpretam as
mensagens
5.1.4
Fatores humanos
A disciplina conhecida como "Fatores humanos" estuda a interface usurio no

ambiente de trabalho do usurio. Associada a Ergonomia que aborda o problema
de projetar um ambiente de trabalho. Aborda aspectos concernentes utilizao
de dispositivos por usurios, tais como:
Fisiologia - caractersticas fsicas - ex. altura
Percepo - habilidades para sentir a informao - visual, auditiva
Cognio - habilidades para processar a informao
48
5.1.5
Metforas
Uma metfora uma imagem mental compreensvel de objetos reais. Os cones

so uma forma de implementar as metforas.
A metfora usual nas interfaces grficas atuais a metfora do escritrio (lixeira,
folders, etc)
A utilizao de uma boa metfora critica para o sucesso da aplicao interativa.
Por isso, a pesquisa na rea de gerao de metforas muito importante e
aborda:
a definio funcional das tarefas da interface
a identificao de problemas do usurio
Nos sistemas de informao da Internet experimenta-se com diferentes tipos de

metforas em funo tanto das tarefas como dos tipos de usurios (imprensa,
telefono, utilitrio, televisor, enciclopdia, centro comercial)
5.1.6
Hipertexto
Df. rede de associaes entre fontes distribudas.

Origem - V. Bush, MEMEX, 1945
T. Nelson, 1965 (def. hipertexto)
Tim Berners-Lee, CERN, Ginebra, WWW, hipertexto como interface de Internet
Modifica forma em que habitualmente se realiza uma leitura

Definio de objetivo
Guiar intuitivamente
Decises, orientao
Treinamento
5.1.7
Origens
A HCI multidisciplinar tendo recebido contribuies de vrias rea de

conhecimento como:
49
Cincia de a computao
Sicologa cognitiva
Sicologa social
Psicologia da percepo
Lingstica
Inteligncia artificial
Antropologia
5.1.7.1
Psicologia cognitiva
Evoluo humana bem-sucedida devido a faculdades mentais para uso e acesso

informao
Mente
Procesador
de
informacin
Figura 12 - Associao de processos mentais ao processamento da informao
Os processos cognitivos bsicos so:
Sensao e percepo de a informao de entrada
Ateno informao relevante
Armazenamento em memria de corta durao enquanto es processada
Adquisicin de habilidades complexas
Produo lingstica de sada oral ou escrita
Resoluo de problemas para tomar aes apropriadas
Planificao de seqncia de aes
50
Existnalgumas limitaes nos processos cognitivos do ser humano, estudados por

Miller (1956) em relao capacidade da memria de curto tempo que reduzida.
S 5 a 9 elementos so lembrveis no curto tempo. Porm, essa capacidade
sensitiva ao contexto: complexidade, familiaridade, possibilidade de ser
discriminados.
Esse estudo tem contribudo Cincia da computao e a HCI (ex. Tamanho dos
menus, tcnicas estruturadas de especificao de requisitos, etc)
5.2 Evoluo
A evoluo da HCI tem se caracterizado por longos perodos de estabilidade
seguidos de rpidos cmbios. Podemos distinguir quatro geraes:
Primeira gerao (50-60)
Segunda gerao (60-80)
Terceira gerao (1970)
Quarta gerao (1990)
Na primeira gerao no existia interao usurio - computador propriamente dita.

Primeiro foram utilizadas as configuraes "plugboards" e logo o processamento
por lotes (entrada por cartes perfurados, sada impressa).
A segunda gerao esteve caracterizada pelo tempo compartido em mainframes e
minicomputadores. A interao usurio computador era realizada a traves de
comandos. Na dcada dos 80 , com o surgimento do PC e os sistemas
operacionais DOS e Unix se popularizam as interfaces de comandos. A
popularidade do PC comea o mudar o tipo de usurio, de especialista a no
especialista. Os usurios no especialistas comeam a ter dificuldades na
utilizao das interfaces de comandos , um dos motivos que leva a terceira
gerao de interfaces.
A terceira gerao de interfaces caracterizada pelo surgimento das interfaces
grficas (GUI ou WIMP). As GUI aparecem j na dcada dos 70, nos laboratrios
da Xerox PARC. so interfaces grficas baseadas em janelas, cones, menus e
dispositivo sinalizador (Figura 13).
51
Figura 13 - Elementos de uma GUI
Estas interfaces foram popularizadas pela

Macintosh no 80s e logo difundidas atravs do
sistema operacional Windows da Microsoft.
A quarta gerao de interfaces comea na dcada dos 90, caracterizada

principalmente por:
Hipertexto e hipermdia
Realidade virtual
Interfaces post-WIMP
Interfaces adaptativas
Manipulao indireta e agentes
52
5.3 Requerimentos de uma interface

Controle por parte do usurio
Intuitividade
Consistncia
Interna: O uso das mesmas convenes e regras para todos os elementos
de a interface
Externa: Seguir as regras dadas pela plataforma utilizada e pelas
convenciones culturais existentes
Claridade e esttica
Retroalimentaao
Reversibilidade
Usabilidade
Funcionalidade
Aceitabilidade do usurio
Aceitabilidade da organizao
Transparncia e reusabilidade
Contraste visual
Legibilidade
5.3.1
Requerimentos de uma GUI
Metfora apropriada
Organizao apropriada de dados, funes, tarefas e roles
Esquema de navegao eficiente
Qualidade da aparncia (como se v)
Seqncia de interao efetiva (como se sente)
53
5.4 O som na interao

Importncia no projeto
facilita a realizao das tarefas (manos e olhos ocupados)
aumenta largura de banda
reduzir necessidade de entrada manual
Reconhecimento de voz (voz para indicar comandos)
reduzir necessidade de sadas grficas
incorpora naturalidade interface
da informao redundante que pode ser de utilidade
mostra informao que no pode mostrar-se graficamente
apresenta melhor que os grficos certos tipos de informao
Informao a comunicar pelo som:
eventos fsicos (queda de um vaso; impressora fora de linha)
cmbios dinmicos (ouve-se quando o lquido chegou ao tope de um vaso; termina-se
impresso de um trabalho)
estruturas anormais (mquina com problema; controle de dispositivos)
Som vs. viso
Som -ouvido uma vez desde diferentes lugares
Objeto -visto desde um lugar muitas vezes
5.4.1
Sistemas de reconhecimento de voz
De controle (ex. "guardar arquivo")

De ditado -reconhecimento e processamento de conversao normal
Dependente (treinado por usurios individuais) maior confiabilidade

Independente - vocabulrio limitado
54
Estagio atual
reconhecimento de voz discreto (pausas)
reconhecimento de voz contnuo para reas especficas
fim e comeo de palavra
Problemas
interferncia da fala com a execuo de tarefas requerendo o uso de memria
temporal
fala e lingstica competem por os mesmos recursos cognitivos
RVoz e PNL - compreenso
5.4.1.1
Sintetizadores da fala
"text to speech"
texto ASCII como entrada
leitura do texto como sada
processamento de morfemas
simples e econmico
5.5 Percepo na interao

ms que ver e ouvir - interpretao de a informao no seu contexto e atribuio
de significado
reconhecimento de padres - brilho, contraste, movimento e cor
visual, auditiva
5.5.1
Percepo visual
objetos relacionados
leis
semelhana - objetos similares como pertencentes a grupo
55
proximidade fsica - objetos prximos formam grupos

lei do fecho - melhor percepo de figuras cerradas
sistema visual permite percepo organizada
caractersticas espaciais de a informao (tamanho, forma, distancia, posio
relativa, textura) so percebidas como propriedades de objetos.
56
Captulo 6 - O projeto de software
Engenharia
de sistemas
Especificao
de requisitos
Engenharia de
requisitos
Especificao
de projeto
Projeto
Codificao
Integrao
e prova
Figura 14 - A fase de projeto no processo de desenvolvimento de software
Especificao do
problema (requisitos)
Soluo computacional
Figura 15 - O mapeamento da especificao do problema soluo computacional
57
P1
P2
P3
S1
P4
S3
P5
Definio do problema
(Especificao de requisitos)
S2
S4
S5
Subproblemas resolvidos
atravs de um ou mais
mdulos do software
Figura 16 A decomposio do problema e da soluo
6.1 Modularidade
O atributo de software que permite abordar sua complexidade
E mais fcil resolver um problema complexo quando ele dividido em partes mais
simples
Independncia funcional
Atributo principal de um bom projeto
Critrios para medir a independncia funcional
Coeso: fora funcional relativa de um mdulo
Acoplamento (conexo): Interdependncia relativa entre mdulos
6.2 Fases do projeto de software

Projeto global
Produto: Arquitetura do software
Projeto detalhado
Produtos:
Detalhes de processamento de cada modulo
58
Projeto de dados
6.2.1
O projeto global
Estabelece a estrutura dos mdulos do software e seus relacionamentos

arquitetura de software
Enfatiza coordenao (interao) sob computao (funcionalidade)
6.2.1.1
Diagramas de estrutura
P
S1
S4
S5
S3
S4
S1
S2 S3 S4 S5
Estrutura 1
S1
S3
S2
S5
S2
Estrutura 3
Estrutura 2
Figura 17 - Mapa estruturado
59
Estabelece hierarquia de
controle entre os mdulos
que compem o software
A
D
H
B
F
E
I
No estabelece
detalhes de
processos
Leque de sada
A
D
H
B
F
E
I
Leque
de
entrada
Figura 18 Leques de sada e entrada
6.3 Tcnicas de projeto
60
?
P
Especificao do
problema (requisitos)
Soluo computacional
Figura 19 Como realizar o mapeamento
6.3.1
Projeto estruturado
Constantes
vitais
Paciente
Dados
do paciente
Monitorar
localmente
Enfermaria
Monitorar
centralmente
Lim
ite
sd
os
pac
ien
tes
S4
Limites das constantes vitais
Mensagem
de aviso
Relatrio
Da
pac dos d
ien e
te
Gerao
de
relatrio
e
sd
do
Da iente
pac
S1
Dados
do paciente
a atualizar
Dados de paciente
Atualizao
de informao
DFD
S2
S5
S3
Diagrama de estrutura
Figura 20 Do DFD ao Diagrama de estrutura
6.3.1.1
Mtodo do projeto estruturado
Expandir DFD
61
Anlise de transformao
Determinar tipo de fluxo de informao
Indicar os limites do fluxo
Gerar mapa estruturado a partir do DFD
Aplicar fatorizao
Refinar mapa estruturado utilizando heursticas de bom projeto
ME
MC
Mdulo
controlador
MT
MS
S
Primeiro nvel de
fatorizao
Controlador
Controlador
Controlador
sadas
chegadas
transformaes
Figura 21 -Anlise de transformao Primeiro nvel de fatorizao
62
Mdulo
controlador
MC
A
ME
C
B
MT
MS
C
A
Segundo nvel de
fatorizao
Figura 22 - -Anlise de transformao Segundo nvel de fatorizao
Heursticas de projeto
Independncia funcional
Reduzir conexo e melhorar coeso
A
BCD
EF
Figura 23 Exemplo de aplicao de heursticas de projeto
63
6.3.2
Projeto detalhado
Produtos:
Detalhes de processamento de cada modulo
Projeto de dados
M o d u lo K
C
G
Figura 24
Seqncia
Repetio
Extenso IF-THEN_ELSE
(DO WHILE)
Seleo de caso
T
F
Condio (IF-THEN_ELSE)
F
(REPEAT UNTIL)
T
F
F
T
T
F
Figura 25 -Construes da programao
estruturada
T
64
IF-THEN-ELSE
Seqncia
1eira tarefa
2da tarefa
3eira tarefa
Condio
Parte
ELSE
Parte
THEN
Repetio
Condio
Parte
DO
WHILE
Parte
REPEAT
UNTIL
Seleo
Condio do
CASE
T
Valor
Valor
Parte
CASE
Condio
Figura 26 -Diagramas de Nassi-Schneiderman
65
Captulo 7 - GERENCIAMENTO E PLANEJAMENTO

DE PROJETOS DE SOFTWARE
7.1 Introduo
A gerncia de projetos abrange todo o processo de desenvolvimento. Para se
conduzir um projeto de software bem-sucedido, vrias etapas tm que ser bem
compreendidas e s o gerenciamento de projetos que oferece essa
compreenso. A gerncia de projeto de software comea antes do trabalho
tcnico, prossegue medida que o software se desenvolve do modelo conceitual
para a realidade e encerra somente quando o software se torna obsoleto. Neste
captulo faremos uma abordagem geral sobre a gerncia de projetos, com nfase
na gerncia de projeto de software, destacando os problemas mais comuns
provenientes da falta de gerenciamento, como conduzir um projeto de
software,quais as mtricas utilizadas que auxiliam no gerenciamento e quais as
fase e funes do planejamento e controle tcnico e administrativo.
7.2 Fundamentos dos projetos

Projetos so executados em todos os setores da economia e representam um
conjunto de esforos complexos interdependentes, exigindo elevado esforo de
gerenciamento. O gerenciamento de projetos garante estrutura, foco, flexibilidade
e controle na busca de resultados.
Um projeto tem pontos claros de incio e fim, uma srie de atividades entre eles e
um conjunto de objetivos.
O gerenciamento de projetos permite focar prioridades, monitorar desempenhos,
superar dificuldades e adaptar-se a mudanas.
Organizar as tarefas de um projeto pode demandar tempo no incio, mas a longo
prazo economiza tempo e esforo, e reduz risco de erros.
A natureza dinmica e interdisciplinar de um projeto traz srias dificuldades para o
seu gerenciamento, quando so usados mtodos tradicionais de administrao.
Problemas mais comuns:

eficincia limitada falta de controle de qualidade tcnica e
planejamento integrado;
66
resultados no relacionais com as necessidades reais

resultante da falta de uma definio do problema, de controle e
falta de avaliao;
atrasos srios nos cronogramas falta de um sistema
conveniente de controle e progresso;
custos excessivos falta de estrutura adequada de estimativa e
controle de custos;
m direo falta de sistema de informao conveniente.
Nos processos de gerenciamento de software todos esses problemas tcnicos e
administrativos so freqentes:
gerncia fraca;
prazos finais impossveis de serem cumpridos;
insatisfao dos usurios;
aumentos dos custos;
aumento na demanda de manuteno.
7.2.1
Como conduzir um projeto de software?
A gerncia de projetos de grande importncia para o sucesso de um

projeto. Seria razovel presumir-se que todos os gerentes de projetos
entendem como coloc-la em prtica e que todos os profissionais
entendem como trabalhar dentro dos limites estabelecidos por ela.
Entretanto, h uma certa dificuldade em gerenciar projetos de software
utilizando mtodos tradicionais de administrao de projetos, pois trata-se
de um produto que possui elementos chaves de gerenciamento.
Antes de que um projeto possa ser planejado, os objetivos e o escopo
devem ser estabelecidos, solues alternativas devem ser consideradas e
as restries administrativas e tcnicas identificadas.Sem essas
informaes impossvel definir estimativa de custos razovel, divises
realsticas de tarefas ou uma programao de projeto administrvel e um
planejamento adequado.
O desenvolvedor de software e o cliente devem definir em conjunto os
objetivos e o escopo do projeto. Os objetivos identificam as metas globais
67
do projeto sem levar em considerao como essas metas sero atingidas. O

escopo identifica as funes primrias que o software deve realizar e tenta
delimitar essas funes de uma forma quantitativa.
Para se conduzir um projeto de software bem-sucedido devemos
compreender:
o escopo do trabalho a ser feito;
os riscos em que incorreremos;
os recursos exigidos;
as tarefas a serem executadas;
s marcos de referncia a serem acompanhados;
o esforo despendido;
a programao a ser seguida.
7.2.2
Como iniciar um projeto de software?

Estabelecendo os objetivos e o escopo;
Considerando solues alternativas
Identificando restries administrativas e tcnicas;
Sem essas informaes impossvel definir estimativa de custos razovel,

divises realsticas de tarefas ou uma programao de projeto administrvel e um
planejamento adequado.
7.2.3
O que considerar no planejamento de projeto de software?

Esforo humano exigido;
Durao cronolgica do projeto;
Custos.
Antes de comear o Planejamento de Projeto de Software, devemos, atravs de

tcnicas administrativas:
68
responder a algumas questes importantes sobre riscos;

desenvolver uma estratgia para atacarmos o problema;
estabelecer um mecanismo para avaliarmos o progresso;
organizar o pessoal que foram escolhidos para construir o
produto.
7.2.4
Os aspectos comuns que devem ser considerados nas

tcnicas administrativas:
Escopo do projeto estabelecido antecipadamente;
Mtricas de software e histrico de aferies passadas so
usadas como base;
Divises do projetos em partes.
7.2.5
Previso de riscos
Para um bom gerenciamento de projeto de software crucial que se faa

a anlise dos riscos.
Passos para se prever riscos:
Identificao;
Avaliao;
Disposio por ordem de prioridades;
Estratgias de administrao;
Resoluo;
Monitorao.
Os passos de administrao de riscos esto organizados num Plano de
Administrao e Monitoramento dos Riscos PAMR, que documenta todo o
trabalho executado como parte da anlise de riscos e usado pelo gerente de
projetos como parte do Plano de Projeto Global.
69
7.2.6
Determinao dos prazos
Existem mtodos de determinao de prazos. O PERT Programa

Evoluation and Revew Techinique (mtodo de avaliao de riscos de
programa ) e o COM Critical Path Method ( mtodo de caminho crtico)
so os dois mtodos de determinao de cronograma que podem ser
aplicados no desenvolvimento de software.
Ambas as tcnicas
desenvolvem uma descrio da rede de tarefas de um projeto.
Na fixao de prazos para projetos de software uma srie de perguntas pode ser
feitas.
Como relacionarmos o tempo cronolgico com o esforo humano?
Muitos gerentes acreditam que se houver atraso s acrescentar mais pessoas e
o problema ser resolvido, mas acrescentar pessoas num projeto tem um efeito
desintegrador. O esforo deve ser distribudo ao longo do processo de
engenharia.
A figura a seguir ilustra uma distribuio de esforo recomendado ao longo das
fases de definio e desenvolvimento
Anlise
e
Projeto
Atividade
de testes
e depurao
Codificao
7.2.7
Monitorao e controle
Com a monitorao e controle de recursos podem ser redimensionadas tarefas

reordenadas, compromisso de entrega modificados para acomodar o problema
que foi descoberto.
7.3 Medidas de software

A princpio parece que a realizao de medies evidente por si mesma,
mas a realidade pode ser bem diferente. A medio muita das vezes leva a
70
muitas dvidas e questionamentos. Atualmente algumas mtricas foram

desenvolvidas a fim de oferecer a gerentes e profissionais tcnicos a devida
compreenso sobre o processo de engenharia de software e sobre o
produto que ele produz. Mas ainda existem muitas controvrsias. Quais as
mtricas apropriadas para o processo e para o produto? Como os dados
que so compilados devem ser usados? justo usar medies para se
comparar pessoas, processo e produtos?
Dificuldades em medir:
O que medir?
Como avaliar as medidas que so obtidas?
As mtricas de software so dividas em 2 categorias:
Medidas diretas
Linhas de cdigo (LOC) produzidas;

velocidade de execuo;
tamanhos de memria;
defeitos registrados;
Medidas Indiretas:
Funcionalidade;
qualidade;
complexidade;
eficincia;
confiabilidade;
Manutenibilidade.
As mtricas de software podem, ainda, ser divididas nas seguintes categoria:
71
mtricas de produtividade (sada do processo de engenharia de

software);
mtricas da qualidade (indica se o software est atendendo s
exigncias do cliente);
mtricas tcnicas (concentram-se na caracterstica do software);
mtricas orientadas ao tamanho;
mtricas orientadas para a funo;
mtricas orientadas s pessoas.
Mtricas tcnicas
Mtricas de qualidade
Mtricas de produtividade
Mtricas orientadas
ao tamanho
Mtricas orientadas
funo
Mtricas orientadas
A seres humanos
Figura 27 - Diviso das mtricas em categorias
Produtividade =
kloc
Pessoa ms
Qualidade =
defeitos
kloc
Engenharia de Software Custo =

72
$
kloc
Documentao =
Pginas de documentao
7.3.1
Mtricas orientadas ao tamanho.
Mtricas orientadas ao tamanho so medidas diretas do software e do

processo por meio do qual ele desenvolvido. No so universalmente
aceitas, pois as medidas giram em torno do uso das linhas de cdigos como
uma medida chave. Os opositores afirmam que as medidas LOC so
dependentes da linguagem de programao, que ela penaliza projetos bem
projetados, porm mais curtos.
7.3.2
Mtricas orientadas funo.
So medidas indiretas. A mtrica orientada funo concentra-se na

funcionalidade ou utilidade do programa.
Ponto por funo so reunidos dados como:
nmero de entradas do usurio;
nmero de sada do usurio;

nmero de consultas do usurio;
nmero de arquivos;
nmero de interfaces externas.
73
Aps os dados acima terem sido reunidos, um valor de complexidade associado

a cada contagem, chamado fator de ponderao, que determinado de forma um
tanto subjetiva.
Os pontos-de-funo sero usados como medidas de produtividade, qualidade e
outros atributos de software:
Produtividade =
FP
Pessoa Ms
Qualidade =
Defeito
FP
Custo =
$
FP
Documentao=Pg. de documentao
FP
A mtrica de ponto-de-funo, como as linhas de cdigo (LOC),

controversa. Os opositores afirmam que o mtodo se baseia parcialmente
em dados subjetivos, no objetivos.
Quando medir?:
Durante o processo de engenharia de software;

Depois que o software foi entregue ao cliente e aos usurios.
7.3.3
Mtricas de qualidade
Nessa categoria incluem-se:

Complexidade do programa;
Modularidade efetiva;
74
Tamanho do programa.
As mtricas usadas aps a entrega concentram-se:
Nmero de defeitos descobertos;
Manutenibilidade do sistema.
As medidas de qualidade existentes so
Corretitute o grau com que o software executa a funo que

dele exigida
Manutenibilidade a facilidade com que um programa pode
ser corrigido se um erro for encontrado ou ampliado se o cliente
desejar incluso e alterao nos requisitos funcionais. Uma
mtrica simples orientada ao tempo o tempo mdio para a
mudana (RATTC);
Integridade mede a capacidade de suportar ataques sua
integridade (hackers e vrus)
Usabilidade - a tentativa de se quantificar se a interface
amigvel ao usurio.
7.3.4
Fatores que influenciam a produtividade do software
fatores humanos tamanho e experincia da equipe de

desenvolvimento;
fatores do problema a complexidade do problema e nmero
de mudanas;
fatores do processo so tcnicas de anlises e projetos que
so usadas, linguagem e ferramentas CASE;
fatores do produto confiabilidade e desempenho do sistema;
fatores relacionados a recursos disponibilidade
ferramentas CASE, recursos de hardware e software.
de
75
7.4 O planejamento de software

7.4.1
Porque planificar?
Estimar recursos requeridos
Definir tarefas a executar
Estimar o esforo requerido
Estabelecer a agenda a seguir
7.4.2
Quando planificar?
Ao longo de todo o ciclo de desenvolvimento de forma a melhorar a

preciso do plano do projeto de software
Comear logo aps o estudo de viabilidade, antes da anlise de requisitos
7.4.3
Fatores que afetam a preciso e a eficcia das estimaes
Baseada em estimaes
Quanto maior a preciso, menor o risco
Fatores que afetam a preciso e a eficcia das estimaes
complexidade das aplicaes
familiaridade com aplicaes similares
tamanho do projeto
disponibilidade de informao histrica
7.4.4
Uma guia para a planificao

1. Determinar o escopo do software
2. Estimar os recursos necessrios para o desenvolvimento
3. Estimar os custos de desenvolvimento
76
4. Avaliar a possibilidade de adquirir software

5. Estabelecer plano cronolgico de tarefas
6. Estabelecer estrutura organizacional da equipe de desenvolvimento
7. Elaborar plano do projeto
7.4.4.1
Escopo do software
Delimitar o que vai ser realizado, claramente e sem ambigidades (disponvel na

especificao do sistema)
Avaliar e eventualmente refinar as funes do software bem como o desempenho
requerido
Avaliar as interfaces com outros elementos do SC (hard, perifricos, pessoas e
procedimentos)
Analisar aspetos vinculados a viabilidade do software (natureza do projeto &
esforo para manter o projeto vivel)
7.4.5
Estimao de recursos
Recursos humanos
Ferramentas de software para o desenvolvimento
Recursos de hardware para o desenvolvimento
tec
Grau de
participao
no projeto
GERENTES
PL. AR PG PD
TU
TI
Fases do
desenvolvimento77
Figura 28 - Estimao de recursos humanos
78
Captulo 8 -
A Reutilizao de software
A Reutilizao de software uma das principias tcnicas para enfrentar a crise de

software: ou problema de construir aplicaes de software confivel de forma
controlada e a um custo acorde s estimaes realizadas
8.1 Conceitos bsicos

8.1.1
Problemas do desenvolvimento de software
Complexidade das aplicaes de software

Crescimento continuo da demanda
Novas reas de aplicao
Custo da manuteno
Confiabilidade
Cmbios nos requisitos das aplicaes
Problemas na definio de requisitos
Tcnicas para prototipao e a programao exploratria
Tcnicas e ferramentas que suportam a reutilizao
8.1.2
Qualidade e produtividade atravs da reutilizao
Melhor produtividade atravs da reutilizao de software j existente

O custo de desenvolvimento pode ser dividido entre varias aplicaes
Maior confiabilidade
componentes de software j testados
Promove a prototipao
Simplifica tanto a manuteno corretiva como evolutiva
79
8.1.3
Problemas atuais da reutilizao
Esforo requerido para criao de componentes reutilizveis (retorno em longo

prazo)
Esforo necessrio para criar, adaptar e integrar componentes
Falta de mecanismos para recuperar software efetivamente
Conhecimento da rea ou domnio da aplicao
Sucesso em reas conhecidas ou domnios estveis
8.1.4 O desenvolvimento orientado a objetos e a reutilizao

Suporte s atividades associadas reutilizao:
Encapsulamento
Polimorfismo
Herana
Instanciao
Passagem de mensagens
8.1.5
Efetividade da recuperao de software
Tamanho repositrio
Browsing vs recuperao direta
Sistemas de recuperao de software baseados em palavras chaves
Vocabulrio controlado
Efetividade depende de qualidade e flexibilidade
Trabalhoso processo de consulta - seleo manual de trminos
Vocabulrio livre
Processo de consulta
simples
80
Efetividade limitada
keyword barrier
8.1.6
Custo da classificao de software
Vocabulrios controlados construdos manualmente

Requisito
classificao automtica
8.1.7
Linguagem natural para consultas e classificao
Descries em LN da funcionalidade dos produtos de software

Fonte de informao uniforme
requisitos
projeto
cdigo
diferentes linguagens de especificao e implementao
Usurios preferem interfaces em linguagem natural para recuperao

Mas informao contextual
incrementa a efetividade da recuperao

Disponibilidade de tcnicas lingsticas
classificao automtica
Conhecimento de domnio e regras de inferncia para compreenso da LN
Extrao e representao de informao para recuperao

Mecanismos de recuperao efetivos para estruturas lingsticas
81
8.1.8
Reusabilidade
Medida da capacidade que objetos ou conceitos - previamente usados em uma

situao particular - tem de ser usados em uma situao nova mas similar
anterior
Reutilizao no migrao
8.1.9
Reutilizao vs. migrao
C d igo
A b s t r a c c i o n e s d e s o f t w a r e d e a l t o n iv e l
a r c h ite c t u r e s , f r a m e w o r k s
dom ain analysis
Figura 29
8.1.10 Algumas definies

The formalization and recording of engineering solutions so that they can be used
again on similar software developments with very little change ... (Rada)
... Using existing software artifacts during the construction of a new software
system (Krueger)
... Reuse of software designed to be reused (Tracz)
... Use of everything associated with a software projet including knowledge (Basili)
... Instantiation of domain specific models through the composition of reusable
parts (Prieto-Diaz)
... The use of existing software knowledge or artifacts to build new software
artifacts (Frakes)
82
8.1.11 que reutilizar?

Ideias, conceitos, conhecimento
ej. Conhecimento da rea do problema
Artefatos, produtos, componentes
ej. cdigo
Metodologas, tcnicas, procedimentos e destrezas
ej. Metodologas para o desenvolvimento de software
8.1.12 Artefatos reutilizveis

Um produto do ciclo de vida de desenvolvimento do software
cdigo (mdulo, sistema)
especificaes de requerimentos e diseo
arquiteturas
casos de teste
8.1.13 Tcnicas
Composicional (blocos de construo)
Gerativa
8.1.14 Alcance
Reutilizao vertical
na mesma rea
lnhas de produo
Reutilizao horizontal
componentes genricos
aplicveis em mltiplas reas
83
8.1.15 Modalidades
Black-box, as-is
White-box, modified
8.2 Evoluo
Praticada informalmente desde que a programao foi inventada
algoritmos, fragmentos de cdigo
colees funcionais
adaptao de sistemas existentes a novos requerimentos
experincias de desenvolvimento
Nascimento da reutilizao formal
Mc Ilroe of Bell Labs, 1968
industria de software baseada em componentes reutilizveis
Peter Freeman, 1981
primeiro projeto universitrio em reutilizao
Ted Biggerstaff e Alan Perlis
8.2.1
first conference on software reuse, 1983
Evoluo na prtica da reutilizao

Cdigo
Abstracciones de software de alto nivel

architectures, frameworks
domain analysis
84
Poucas melhoras atravs da reutilizao de cdigo
8.3 O desenvolvimento de software baseado na reutilizao
Custos
Benefcios
Ponto de igualdade
Custos
Anos
Perodo de amortizao
8.3.1
Desenvolvimento para reutilizao
85
8.3.2
Qualificao e generalizao
Generalizao
Obteno de componentes genricos a partir de componentes especficos
Tecnicas
abstraction
reverse engineering
domain analysis
Custo de construo
utilidade
funcionalidade reutilizvel
variedade de funes
Qualidade
corretitude
compreenso
testabilidade
facilidade de modificao
desempenho
8.3.2.1
Classificao
Cataloga um componente de software em um repositrio mapeando o componente

em uma representao interna que ser utilizada na sua posterior recuperao
conjunto de trminos
estrutura de representao de conhecimento
indices
vocabulario libre ou controlado
86
8.3.2.2
Evoluo dos repositrios
Evoluo do domnio das aplicaes

Melhorar a representao interna de forma de fazer mais efetiva e simples a
recuperao
Manter no repositorio s aqueles componentes com real potencial de reutilizao e
eliminar os obsoletos
Melhorar a informao
componentes
disponvel
para
compreenso
adaptao
dos
Refazer o projeto dos componentes do repositrio (ou sus hierarquias) para fazelos mais reusveis
Incluir:
experincia de reutilizao dos usurios
frequencia com a que ou componente reutilizado
8.3.3
8.3.3.1
Desenvolvimento com reutilizao
Recuperao
Componentes potencialmente reutilizveis, que satisfazem requerimentos

especficos dos usurios so buscados e extrados dos repositrios
busca exploratria em uma hierarquia (browsing)
87
x vnculos hipertexto ou hipermdia

recuperao direta
Recuperao direta
O usurio descreve as caractersticas de um componente atravs de uma consulta
e ou sistema recupera uma lista de componentes com funcionalidade similar
especificada na consulta
8.3.3.2
Recuperao
OU sistema de recuperao pode incluir medidas que ajudam usurio a avaliar ou

potencial de reutilizao de um componente recuperado
freqncia de reutilizao
qualidade da documentao
complexidade do componente (tamanho, nmero de entradas e sadas, etc.)
8.3.3.3
Adaptao
Um componente de propsito
requerimentos especficos
general
especializado
para
satisfazer
Tcnicas:
Instanciao de parmetros
Herna (simples, mltipla)
Transformaes
Refinamento
8.3.3.4
Composio
Componentes selecionados e eventualmente especializados so combinados para

construo de um sistema ou subsistema
linguagens de interconexo de mdulos (MIL)
88
8.4 Abstraes de software para a reutilizao

para representar os componentes de software reutilizveis
Que uma abstrao de software?

Uma descrio concisa de um artefato de software que descarta os detalhes
para ele.
Q u e faz
E s p e c ific a o
C o m o o faz
R e a liz a o
Figura 30
Niveles de uma abstrao
Especificao
Primeiro nvel
Realizao A
EspecificaoB
Segundo nvel
Figura 31 - Hierarquia de abstraes
Nvel mais baixo: cdigo de mquina
8.4.2
Partes de uma abstrao
Variable part Fixed part
... V
n
Fixed part
Hidden
Fixed
partpart
V1
Especificao
Realizao
Hidden part
Figura 32 - Partes de uma abstrao
Parte fixa
caractersticas invariantes da realizao
visivel na especificao
Parte varivel
caractersticas variveis da realizao
visivel na especificao
da origem a um conjunto de realizaes alternativas
90
Parte oculta
detalhes da realizao
no visvel na especificao
8.5 Efetividade das tcnicas de reutilizao

8.5.1
Critrios para medir a efetividade
Distancia cognitiva
Efetividade de abstraes
Aplicabilidade das abstraes
Recuperao
Adaptao
Integrao
8.5.1.1
Distancia cognitiva
Mede ou esforo intelectual de os desenvolvedores de S/W para transformar uma

aplicao
de uma fase do ciclo de desenvolvimento seguinte
da especificao de requerimentos al sistema executvel
As tcnicas de reutilizao devem buscar a minimizao da distancia cognitiva

Formas de minimizar a distancia cognitiva
Utilizar abstraes cujas especificaes so concisas e expressivas
Maximizar a parte oculta das abstraes
Automatizar ou mapeamento da especificao realizao
91
8.5.2
Analise de efetividade das tcnicas de reutilizao
linguagens de alto nvel

Reutilizao had-hoc de cdigo e projetos
Reutilizao de componentes de cdigo
A reutilizao em ou DOO
linguagens de muito alto nvel
Arquiteturas de software
8.5.2.1
Linguagens de alto nvel
Especificao
construes do HLL
Realizao
padres em linguagem de mquina
Recuperao
manuais, memria do programador
Adaptao
preenchido de slots em construes parametrizadas da linguagem
Integrao
regras de interconexo de mdulos do HLL
Efetividade das HLL
Boas abstraes
Mapeamento automtico - compilador
92
Programador no necessita conhecer detalhes nem do compilador nem das

linguagens ensambladores.
Distancia cognitiva grande
Grande aplicabilidade
8.5.2.2
Reutilizao informal de cdigo e projeto
Esp. informal
conceitos de projeto adquiridos atravs da experincia
na memria dos desenvolvedores
Realizao
fragmentos de cdigo fonte
Recuperao
manual, memria dos programadores
Adaptao
edio manual
conhecimento de detalhes de baixo nvel
Integrao
adaptao de fragmentos e, possivelmente, al contexto
Efetividade da reutilizao informal

Distancia cognitiva relativa
efetividade restringida a informalidade
Mapeamento manual
No existe uma forma sistemtica de compartir abstraes
Aplicabilidade dependente do programador
8.5.2.3
Componentes de cdigo
Especificao
descries de componentes em um repositrio
93
Realizao
mdulos, subsistemas, classes
Recuperao
dependente
qualidade abstraes
tcnicas de classificao e recuperao
Adaptao
requere componentes genricos de boa qualidade
Integrao
composicional
linguagens de interconexo de mdulos
Efetividade da reutilizao de componentes de cdigo
Aplicabilidade restringida
repositrios de domnios especficos
Adequada em domnios
bem conhecidos
estveis
colees funcionais
Distancia cognitiva pode ser grande
8.5.2.4
Paradigma de orientao a objetos
Objeto
Classe
Mensagens
Herna
Reutilizao
94
Objeto
Entidade independente com:
estado interno (atributos, variveis de instancia)
memria donde pode armazenar-se e atualizar-se informao (estrutura de dados)
comportamento (mtodos, servios e funes)
conjunto de funes para
atender demandas de processamento de outros objetos
solicitar processamento a outros objetos
instancia de uma classe
classe
Descreve uno ou ms objetos com as mesmas variveis de instancias e
comportamento
Tanto a estrutura como ou comportamento descrita na classe
os objetos de uma classe diferem por ou valor de sus variveis de instancia
Exemplos
Class = Number, Objet = 4
Class = Mouse, Objet = Mickee Mouse
Troca de mensagens
Mecanismo de comunicao entre objetos
Solicita a execuo de um mtodo
O objeto receptor executa ou mtodo e retorna informao ao objeto que o
solicitou
Exemplo:
Message: 4 fatorial
Answer: 24
Uma mensagem pode ativar diferente comportamento dependendo do objeto

destino
95
herana
Mecanismo para definir uma nova classe a partir de outra classe
Subclasse/superclasse
subclasse
Herda a estrutura de dados e os mtodos da superclasse
pode agregar variveis de instncia a estrutura de dados
pode agregar novos mtodos
pode cambiar a implementao dos mtodos herdados
hierarquia de classes
subclases que so superclasses de outras classes
herana simples vs. herana mltipla

Reutilizao no DOO
Aplicaes construdas integrando classes selecionadas de um repositrio
A criao de novas classes deveria ser minimizada
novas classes criadas considerando sua futura reutilizao
Tcnicas de reutilizao
herana
classes abstratas
Instanciao
8.5.2.5
Especificao
descrio formal de um algoritmo ou estrutura de dados (esquema)
Realizao
esquema instanciado em cdigo fonte
Recuperao
ferramentas do repositrio
96
Adaptao
instanciao de parmetros
Integrao
composicional
linguagens de interconexo de mdulos
algoritmos de Knuth, PARIS, LIL
Efetividade da reutilizao de esquemas de software

Amplia aplicabilidade
Distancia cognitiva relativa
Locao, compreenso e utilizao de esquemas pode ser difcil
8.5.2.6
Especificao
descrio de todas as partes do domnio que podem ser modeladas por ou
gerador
Realizao
sistemas executveis produzidos por ou gerador
Artefatos reutilizados
arquitetura global dos sistemas
projeto arquitetnico e detalhado
estruturas de dados e algoritmos

reutilizao da totalidade de3l projeto de uma aplicao
geradores de aplicaes
Recuperao
repositrios de geradores ?
Adaptao
especificao para ou gerador
97
Integrao automtica
analise de domnio
til em domnios donde
muitos sistemas similares necessitam ser desarrolhados
sistemas que evolucionam rapidamente
so necessrios prottipos
Metageradores
Exemplos de geradores
DBMS
geradores de informes
geradores de interface-usuario
geradores de parsers e compiladores
Lex and Yacc
Efetividade dos geradores de aplicaes
Mapeamento automtico
Abstraes do domnio
Distancia cognitiva mnima
o maior parte das atividades do ciclo de desenvolvimento automatizado
Aplicabilidade limitada
8.5.2.7
Linguagens de muito alto nvel (VHLL)
Especificao
construes do VHLL
Realization
construes do HHL
Recuperao
98
memria do programador
manuais
Adaptao
preenchido de parmetros nas construes da linguagem
exemplos:
SETL
Ainda muito ineficientes
Efetividade das HLL
Mapeamento automtico
linguagens de especificao executveis
Abstraes independentes do domnio
Abstraes matemticas de alto nvel
8.5.2.8
Seqncia de transformaes
especificao formal a implementao executvel
Especificao
regras de transformao
Realizao
seqncia de transformaes
Recuperao
biblioteca de transformaes
Adaptao
irrelevante
Implementaes ms eficientes que os VHLL
99
exemplos
PADDLE , Glitter
Efetividade
8.5.2.9
Arquiteturas
A estrutura de componentes de um programa ou sistema, sus inter-relaes e

princpios que guiam seu projeto e evoluo em ou tempo
Especificao
linguagem de domnio
Realizao
componentes da linguagem de domnio
Recuperao
conjunto de arquiteturas de software reutilizveis
Adaptao
transformaes ou refinamentos de componentes
Integrao
linguagem de interconexo de mdulos
Efetividade das arquiteturas

Reutilizao da totalidade de um projeto de software
Abstraes do domnio
Mapeamento automtico ?
DRACO
domain analysis
Aplicabilidade
arquiteturas como blocos de construo
Distancia cognitiva reduzida
100
a maior parte das atividades do ciclo de vida automatizveis
101
CURSO DE ESPECIALIZAO EM ANALISE E PROJETO

DE SISTEMAS
Ementa:
A importncia do software, caractersticas do software e aplicaes, a crise
software, mitos do software. Paradigmas de desenvolvimento. Os requisitos
usurio. Princpios de especificao do software. Planejamento
desenvolvimento. O projeto de software. Uma introduo a tpicos avanados
Engenharia de Software.
do
do
do
da
Bibliografia :
Pressman, Roger, Software Engineering: a Practitioner's Approach. Ed. McGraw Hill. 4a. Edio, 1997.
Ince, D. C. Chapman and Hall, Software Engineering. 1989
Yourdon , Currents Pratices in Software Development: A Guide to Successful

System. Ed. Press-Prentice Hall. 1984.
Sommerville, Ian, Software Engineering, Ed. Addison-Wesley, 4a. Edio, 1992
102

Apostilha ES2003

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apostilha ES2003

Uploaded by

Copyright:

Available Formats

ENGENHARIA DE SOFTWARE

INTRODUO ENGENHARIA DE SOFTWARE

1.1 ALGUMAS DEFINIES

2.1 O CICLO DE VIDA EM CASCATA

3.1 TAREFAS DA ENGENHARIA DE SISTEMAS

4.8.2.1 O domnio da informao

INTERAO HUMANA - COMPUTADOR

5.1 CONCEITOS BSICOS

GERENCIAMENTO E PLANEJAMENTO DE PROJETOS DE

7.3 MEDIDAS DE SOFTWARE

7.4.4 UMA GUIA PARA A PLANIFICAO

8.1 CONCEITOS BSICOS

Introduo Engenharia de Software

A Engenharia de software a disciplina que estuda tcnicas para o

1.1 Algumas definies

1.2 Objetivos da Engenharia de Software

Incrementar a produtividade no desenvolvimento e manuteno dos SC

Diminuir os custos de desenvolvimento e manuteno

1.3 A importncia do software

Hoje, os problemas esto centrados em reduzir custos de desenvolvimento e

1.5 Sistema de computao

Os elementos de um sistemas de computao so:

Software: Produtos do ciclo de desenvolvimento utilizados para realizar o

Hardware: Dispositivos eletrnicos que proporcionam a capacidade de

Pessoas: Indivduos (Usurios, Clientes, Operadores de hardware e

Bases de dados: Conjunto grande e organizado de informao ao qual se

Documentao: Manuais e outra informao que explica o uso e a

Procedimentos: Os passos que definem o uso especfico de cada elemento

Evoluo dos sistemas de computao

Podemos distinguir trs eras em relao evoluo dos sistemas informticos:

processamento de software aplicativo

processamento da rede de comunicao (controle das interfaces entre os

O crescimento nos sistemas de teleprocessamento comea a provocar sobrecarga

So propostos mtodos e ferramentas avanadas para o desenvolvimento de

incremento exponencial no desenvolvimento de sistemas Web

crescimento na complexidade das aplicaes

Reutilizao e desenvolvimento orientado a objetos

objeto como abstrao de software

Novas reas de aplicao:

Tendncias: sistemas baseados em conhecimento, agente como abstrao

Evoluo nas modalidades de processamento da informao

Os sistemas de processamento da informao tem evolucionado de sistemas de

Nesta modalidade de processamento, vrias mquinas com capacidade de

Centralizao das atividades num nico local para otimizar (codificao,

Primeiros SGBD - Dados centralizados

Economia de escala: Concentrao justificada pela necessidade de dividir

Centralizao reforava a influencia do CPD na empresa

administradores da informao da empresa

O processamento centralizado apresentava os seguintes problemas:

Software de controle - maior parte do tempo de processamento

Congestionamento do software aplicativo

Interrupo no processamento - paralisao de atividades

Saturao de determinada tecnologia

Saturao de recursos do sistema centralizado por incremento na

Na medida que o sistema utilizado por mais usurios, aumenta sua

Novas Tecnologias substituem Tecnologias que j alcanaram seu

As limitaes do processamento centralizado foram a justificativa econmica para

micros, minicomputadores e mainframes

processamento e dados localizados em diferentes centros sem

aumento dos custos

O principal fator contribuinte para

Usurio - funes de entrada de dados e consulta de dados armazenados

terminais locais ligadas diretamente ao computador central

terminais remotas ligadas atravs de redes locais ou de longa distancia