Engenharia de Software

Luiz Felipe Mendes

luizfelipe.carvalho.mendes@gmail.com

O que vem ocorrendo com o

desenvolvimento de software?

o conhecimento sobre tcnicas que funcionam

pouco partilhado
o conhecimento no est suficientemente
organizado de forma a poder ser usado como
referncia
a Cincia da Computao tem feito contribuies
tericas importantes mas estas tem influenciado
pouco a prtica do desenvolvimento de software.

O termo Engenharia de Software

comumente usado para referir-se a:
modelos de ciclo de vida
mtodos e ferramentas de
desenvolvimento
tcnicas para estimativas de custos
documentao
tcnicas para controle de qualidade

Engenharia de Software

enfoque sistemtico para o

desenvolvimento, operao, manuteno
e descontinuao do software
IEEE Glossary os Software Terminology

Histrico da Engenharia de Software

Histrico da Engenharia de Software

Histrico da Engenharia de Software

Sculo XXI
Desenvolvimento

baseado na Web
Desenvolvimento para dispositivos mveis
OO e componentes
Qualidade
Gesto do conhecimento
..........

Cincia da Computao e Engenharia

de Software

Em resumo a ES trata de projeto e

desenvolvimento de software de alta
qualidade.

Fatores que influenciaram a Engenharia

de Software

tempo crtico de mercado para produtos comerciais

mudanas na economia no que tange a queda de
preos do hardware e maior custos de desenvolvimento
e manuteno
disponibilidade de computadores pessoais e dispositivos
mveis
ampliao das redes locais e de reas cada vez mais
extensas
adoo de tecnologia de Orientao a Objetos
interfaces grficas para o usurio

Caractersticas do Software

o software desenvolvido ou projetado por engenharia,

no manufaturado no sentido clssico

o software no se desgasta

os custos do software esto centrados no trabalho de

engenharia, no processo
o software se deteriora
a manuteno do software complexa

a maioria dos software feita sob medida

o crescente uso da Orientao a Objetos e tcnicas de

reutilizao tem contribudo para o reuso de componentes de
software

Categorias do Software

Software Bsico, Software de Tempo

Real, Software Comercial, Software
Cientfico e de Engenharia, Software
Embutido ou Embarcado, Software de
Computador Pessoal, Software de
Inteligncia Artificial, Software do Tipo
Hipermdia,.....

Crise do Software

Conjunto de problemas que so

encontrados no desenvolvimento de
software, como:
software

que no funciona
manuteno de um volume crescente de
software existente
atendimento a uma demanda cada vez maior,
etc.

Crise do Software

Relatrio do Standish Group (relatrio do Caos 1995)

Em 1995 os Estados Unidos gastaram $81 milhes em

projetos de software que foram cancelados.
31% dos projetos foram cancelados antes de estarem
concludos.
53% excederam mais de 50% de sua estimativa de
custo.
Somente 9% dos projetos das grandes empresas foram
entregues em tempo e estimativa.

Problemas
falta de dados histricos sobre o processo
de desenvolvimento
insatisfao de clientes
qualidade suspeita do software
manuteno difcil

Projetos de Software
O desenvolvimento de software ainda
imprevisvel.
Somente 10% dos projetos de software
so entregues com sucesso dentro das
estimativas de oramento e custo.
O nvel de software jogado fora e que tem
necessidade de re-trabalho um
indicativo de processo imaturo.

Processo de Software

Elementos da Engenharia de Software:

Mtodos
Ferramentas
Procedimentos

Mtodos

Mtodos proporcionam os detalhes de como fazer

para construir o software. Envolvem tarefas como:
planejamento e estimativa de projeto, anlise de
requisitos, projeto de estrutura de dados,
algoritmos, codificao, teste e manuteno.
Muitas vezes introduzem uma notao grfica ou
orientada linguagem especial e introduzem um
conjunto de critrios para a qualidade do software.

Ferramentas

As ferramentas proporcionam apoio

automatizado ou semi automatizado aos
mtodos.

Procedimentos

Os procedimentos constituem o elo de ligao

que mantm juntos os mtodos e as ferramentas e
possibilita o desenvolvimento racional e oportuno do
software de computador.
Os procedimentos definem a seqncia em que os
mtodos sero aplicados, os produtos que devero
ser entregues, os controles que ajudam a assegurar
a qualidade e a coordenar as mudanas e os
marcos de referencia que possibilitam aos gerentes
avaliar o progresso.

Elementos

Um mtodo ou tcnica um procedimento formal para

produzir algum resultado.
Uma ferramenta um instrumento ou sistema automatizado
para resolver alguma coisa da melhor forma.
Um procedimento um conjunto de ferramentas e tcnicas
que juntas geram um produto.
Um paradigma representa uma abordagem ou filosofia para
construir um software.

Engenheiros de software utilizam todos esses recursos

para desenvolver software de alta qualidade.

Atores da Engenharia de Software

Clientes: empresas, companhias, organizaes ou

pessoas que pagam pelo desenvolvimento do
software
Desenvolvedores: companhia, empresa, ou
pessoas que esto desenvolvendo o sistema para o
cliente.
Usurios: pessoas ou pessoas que iro usar o
software.
Outros: subcontratados, periferia, etc.

Membros de uma equipe de

desenvolvimento
Analista
Projetista
Programador
Responsvel por testes
Instrutor
Outros

Para quem a Engenharia de Software

Engenheiros de Software
Analistas de Sistemas
Projetistas de Software
Gerentes de Projeto
Equipe de qualidade
Equipe de teste
......

Conceitos

O que Software?
Instrues

(programas de computador) que,

quando executadas, produzem a funo e o
desempenho desejados
Estruturas de dados que possibilitam que os
programas manipulem adequadamente a
informao
Documentos que descrevem a operao e o uso
dos programas

Aplicaes do Software
O Software pode ser aplicado a qualquer
situao em que um conjunto previamente
especificado de passos procedimentais
(algoritmo) tiver sido definido
Notveis excees a essa regra so o
software de sistemas especialistas e o
software de rede neural

Tipos de Software

Software Bsico

uma coleo de programas escritos para dar

apoio a outros programas (ex.: SO; software de
rede; drivers; compiladores; etc)
A rea de sw bsico caracterizada pela forte
interao com o hw, intenso uso por mltiplos
usurios, operaes concorrentes que exigem
escalonamento, estruturas de dados complexas e
mltiplas interfaces externas

Tipos de Software

Software de Tempo Real

um software que monitora/analisa/controla

eventos do mundo real
Um sistema de tempo real deve responder
dentro de restries de tempo estritas, caso
contrrio podem acontecer conseqncias
desastrosas

Tipos de Software

Software Comercial / Administrativo

Maior

rea de aplicao de sw atualmente

Lidam com informaes comerciais/ administrativas
Sistemas distintos (folha de pagamento; contas a
pagar/receber; controle de estoque; etc) evoluram
para o Sw de Sistemas de Informao
Administrativa, que do acesso a um ou mais
banco de dados contendo informaes comerciais/
administrativas

Tipos de Software

Software Cientfico e de Engenharia

Caracterizados

por algoritmos de processamento

de nmeros (ex.: dinmica orbital de naves
espaciais; astronomia; biologia molecular), porm
alguns tipos de aplicaes nesta rea esto se
afastando dos algoritmos numricos convencionais
(ex.: projeto assistido por computador; simulao
de sistemas e outras aplicaes interativas e
comeam a assumir caractersticas de tempo real)

Tipos de Software

Software Embutido (embedded systems)

Reside

na memria s de leitura e usado para

controlar produtos e sistemas para os mercados
industriais e de consumo
Pode executar funes muito limitadas e
particulares (ex.: controle de teclado dos fornos
de microondas) ou oferecer recursos funcionais
de controle mais complexos (ex.: funes digitais
em automveis)

Tipos de Software

Software de Computador Pessoal

Processamento

de textos; planilhas
eletrnicas; diverso; aplicaes financeiras
pessoais, so algumas das centenas de
aplicaes para computador pessoal

Tipos de Software

Software de Inteligncia Artificial (IA)

Faz

uso de algoritmos no-numricos para

resolver problemas complexos que no sejam
favorveis computao convencional
Atualmente a principal rea da IA a dos
sistemas especialistas tambm chamados
Sistemas baseados em conhecimento

Tipos de Software

Software de Inteligncia Artificial (cont.)

Outras

reas da IA so: reconhecimento de

padres (voz e imagens); jogos; demonstrao de
teoremas
Nos ltimos anos desenvolveu-se um novo ramo
da AI: Redes neurais artificiais

Uma rede neural simula a estrutura dos processos

cerebrais e pode levar a uma nova classe de software
que consegue reconhecer padres complexos e
aprender com a experincia passada

Fatos e Falcias em
Engenharia de
Software
GLASS, R. L. Facts and Fallacies
of Software Engineering. AdisonWesley, 2002.

Gesto - Pessoas
Fato 1
O Fator mais Importante no Trabalho com Software no so as
ferramentas e Tcnicas Usadas pelos Programadores, mas sim a
Qualidade dos Prprios Programadores.

Isso no significa que as tcnicas e ferramentas no sejam

importantes, porm a qualidade dos desenvolvedores acaba sendo
maior. No adianta utilizar o melhor mtodo, com a melhor
ferramenta e fazer uso da melhor tcnica se o desenvolvedor no
tiver um nvel aceitvel de qualidade, at mesmo para ter
capacidade e conhecimento para utilizar estas tcnicas e
ferramentas.

Gesto - Pessoas
Fato 2
Os melhores programadores so at 28 vezes melhores que os piores
programadores, em contra-partida o salrio nunca proporcional.

Robert Glass(1995) diz em seus princpios:

Princpio 132- Poucas boas pessoas so melhores que muitas com pouca
qualidade.
Princpio 141- H enormes diferenas entre os engenheiros de software.

Comentrios:

Os profissionais no devem focar em apenas uma tecnologia e devem buscar

atualizao constante.
Nas empresas sempre ter esta diferena de qualidade, e bom, porque
existe necessidades especficas para cada nvel de profissional dentro de um
mesmo projeto.

Gesto - Pessoas
Fato 3
Adicionar pessoas a um projeto que est atrasado o torna mais
atrasado.

A Lei dos Brooks consiste em Acrescentar mais pessoas a um

projeto que est atrasado s aumentar o atraso do projeto.
A entrada de novos profissionais geram novos atrasos, exigindo
tempo extra para explicar aos novatos o que os outros j sabem.
Existe a complexidade e custos de comunicao de um projeto que
crescem com o quadrado do nmero de desenvolvedores,
enquanto o trabalho feito cresce somente linearmente.
Os seguidores de Brooks tm uma forma alternativa e mais
contundente de enunciar o princpio: "mesmo juntando nove
mulheres no possvel fazer um beb em um ms".

Gesto - Pessoas
Fato 4
O ambiente de trabalho tem um profundo impacto na produtividade e
na qualidade do produto.

Este conceito, j era mencionado com a filosofia dos 5s:

Seiri (descarte): concentrao no essencial;

Seiton (arrumao): organizao do espao e mtodos de trabalho;
Seisoh (limpeza): limpeza do espao fsico e de todos itens;
Seiketsu (asseio): padronizao para guardar as ferramentas de trabalho;
Shitsuke (disciplina): postura interna.

Gesto Ferramentas e Tcnicas

Fato 5
Exagero e Intrigas so os maiores problemas para as empresas de
desenvolvimento de software.

Na dcada de 50 que foi o surgimento das idias na rea da

engenharia de software. Fred Brooks (1987) fala sobre as balas de
prata para solucionar problemas. A utilizao das novas tcnicas, no
agregam mais 30% de melhorias.
Boatos:
Sobre as linguagens de 4 gerao: no seria necessrio programadores;
Ferramentas CASE : ser uma automao em programao;
Extreme Programming : ser o futuro a ser seguido.
Robert Glass afirma que existe um grande fosso entre estas tcnicas e a
realidade.

Comentrios:

- muito importante ter cautela na hora de escolher determinada ferramenta.

Gesto Ferramentas e Tcnicas

Fato 6
Aprender uma nova ferramenta ou tcnica inicialmente diminui a
produtividade do programador e a qualidade do produto. O benefcio
final obtido somente aps quando a curva de aprendizado
ultrapassada. Portanto, vale a pena adotar novas ferramentas e
tcnicas, mas somente (a) se o seu valor visto realisticamente e (b)
se houver pacincia para medir os benefcios.

Gesto Ferramentas e Tcnicas

Fato 7
Os desenvolvedores de Software falam muito de ferramentas. Eles
avaliam muito pouco, compram algumas mas no usam
praticamente nenhuma.

As ferramentas poderiam
ser melhor aproveitadas pelos
desenvolvedores de Software. Uma dcada ou mais atrs, todos
pareciam acreditar que as ferramentas CASE fariam parte do futuro. Se
houvesse uma definio, a probabilidade de uso seria maior.

A grande controvrsia que dada a escolha de algo novo ou algo velho,

eles preferem algo novo, mesmo no tendo certeza se podero ou no
concluir suas tarefas. O problema que existe uma cultura que exige
muito da programao.

Gesto - Estimativas
Fato 8
Uma das causas mais comuns de projetos que no esto sob controle
em funo de ms estimativas

As estimativas so mal feitas no campo do software. A maioria das

estimativas semelhante s metas que desejamos alcanar. Para piorar,
no se tem idia de como melhorar essas pssimas prticas. O resultado
que todo mundo tenta reunir um alvo de estimativa impossvel, por isso,
atalhos so tomados e as boas prticas so ignoradas.

Ns tentamos todos os tipos de abordagens aparentemente razoveis para

melhorar a nossa capacidade de estimar. Para comear, contratamos
pessoas "experts" e programadores de software.

importante notar que um projeto errado, pelo menos aquelas que

resultam em ms estimativas, no ocorrem geralmente porque os
programadores fizeram um mau trabalho. Esses projetos se tornaram ruins
porque o objetivo foi irreal.

Gesto - Estimativas
Fato 9
A maioria do software tem sua estimativa realizada no incio do ciclo
de vida. Isto faz sentido, at perceber que as estimativas so
obtidas antes dos requisitos serem definidos e, portanto, antes do
problema ser entendido. Geralmente a estimativa ocorre na altura
errada.

As estimativas ocorrem na hora errada, pois para desenvolver um bom

projeto preciso conhec-lo para saber quais as suas expectativas.
Segundo o autor primeiro feita toda a estimativa para depois
conhecer o projeto e levantar os requisitos.

A controvrsia neste caso bem simples, algum precisa tomar a

iniciativa para que isso seja mudado.

Gesto - Estimativas
Fato 10
A maioria das estimativas feita ou pela alta gerncia ou pelo pessoal
de marketing, e no pelos profissionais que vo de fato construir o
software, ou os seus gerentes tcnicos. Estimativas, portanto, so
feitas pelas pessoas erradas.

Na maioria das vezes, a estimativa de software feita por pessoas que

querem o produto. Alta gesto, Marketing, Clientes e Usurios. Em outras
palavras estimativa de software, atualmente mais pela vontade do que
pela realidade.
At mesmo gerentes experientes podem tomar decises erradas quando a
presso poltica est envolvida. E h quase sempre um preo a
ser pago para trabalhar por um prazo irrealista. Esse preo na maioria das
vezes pagos em termos humanos (reputao, moral, sade, entre outros) e
pode at ter questes financeiras envolvidas.
A controvrsia, no se o fato verdade, mas por que o fato verdade. E
at que essa controvrsia seja resolvida, o campo de software continuar
tendo muita dificuldade.

Gesto - Estimativas
Fato 11
As previses de Software so raramente ajustadas na medida que o
projeto de software avana. Desse modo, as estimativas feitas no
tempo errado, por pessoas erradas, normalmente so de difcil
correo.

Uma vez que o projeto passou da data em que foi estimado, existe uma
desconfiana sobre quando o produto ficar pronto.
Segundo Ruth Ferreira Roque Rossi (1999) , o caso do aeroporto
Denver destaca-se somente por sua notoriedade, pois estudos vm
mostrando que:

para cada seis novos sistemas de grande escala que so colocados em operao
dois outros so cancelados;
h uma mdia de atrasos dos projetos de desenvolvimento de software em
relao ao orado de 50% .
75% de todos os sistemas grandes podem ser considerados operando com
falhas, isto , no funcionam como era esperado ou no so totalmente usados.

Gesto - Estimativas
Fato 12
Em uma m estimativa, no existe uma grande preocupao com os
objetivos do projeto. Embora todos estejam de certa forma
preocupados

Projetos de softwares esto quase sempre administrados por tempo. O

tempo gasto para concluso de um projeto o fator mais importante
para o gerenciamento. Nos projetos so definidos metas a curto e a
longo prazo para que seja avaliado o sucesso ou fracasso do mesmo.
Porm pode haver outros tipos de administrao, como por exemplo:
por produto, assunto, riscos, objetivos do negcio e qualidade.
Gerenciamento por horrio causam efeitos posteriores. Em alguns
casos para se cumprir a estimativa, os programadores aceleram o
desenvolvimento do software, o que pode provocar a entrega de um
produto inacabado e de baixa qualidade.

Gesto - Estimativas
Fato 13
Existe uma desconexo do gerenciamento entre os programadores.
Em um estudo de um projeto foi visto que faltaram previses em
sua gesto diante de um fracasso, o tcnico participante viu-o
como o mais bem sucedido projeto que j tinha trabalhado.

Metas estimadas costumam nem chegam perto de serem alcanadas.

Mas em relao aos produtos de software, podem ter sido bem feitos.
Porm pode haver outros tipos de administrao, como por exemplo:
por produto, assunto, riscos, objetivos do negcio e qualidade.

Gesto - Estimativas
Fato 14
A resposta sobre um estudo de viabilidade quase sempre sim.

s vezes at conseguem cumprir o projeto em um curto prazo, porm,

quando pensam que podem produzir um software sem erro em um curto
prazo, no final a correo leva um tempo ainda maior do que fazer a
anlise, a concepo e a codificao juntas.

A controvrsia neste caso bem simples, frequentemente esto dando

a resposta errada.

Gesto - Reuso
Fato 15
Reutilizao em baixo nvel (bibliotecas de sub-rotinas) comeou
aproximadamente h 50 anos e um problema bem resolvido.

Herana
Reescrita

Gesto - Reuso
Fato 16
Reutilizao em alto nvel (componentes) continua sendo um
problema no resolvido, mesmo que todos concordem esse um
problema importante e de resoluo desejvel.

Deficincia no processo de desenvolvimento;

Demasiada dependncia entre componentes de software;
Projetar , projetar, projetar ...

Gesto - Reuso
Fato 17
Reutilizao em alto nvel trabalha melhor em famlias de sistemas
relacionados e, portanto, dependente de domnio. Esse fato
estreita o potencial de aplicabilidade da reutilizao no nvel mais
alto.

Interligao entre sistemas distintos;

Interoperabilidade de dados.

Gesto - Reuso
Fato 18
Existem duas "regras de trs" na reutilizao: (a) trs vezes mais
difcil construir componentes reutilizveis como utilizao nica de
componentes, (b) componentes reutilizveis devem ser julgados
com base em trs diferentes aplicaes antes que seja
suficientemente geral para aceitar em uma biblioteca de
reutilizao.

Cenrio empresarial atual;

Alta demanda de novos sistemas;
Abordagem de reutilizao;
Benefcios;

Gesto - Reuso
Fato 19
Modificao do cdigo reutilizado particularmente um erro. Se mais
de 20 a 25% de um componente est a ser revisto, mais eficiente
e eficaz reescrev-lo a partir do zero.

Programas legados;
Linguagem de programao ultrapassada;
Necessidade de novas funcionalidades.

Gesto - Reuso
Fato 20
Padres de projeto uma soluo para problemas referentes a
reutilizao de cdigo.

Reutilizao de pequenas e grandes partes de cdigo

Problema em modificar um componente de software para reutilizao
Utilizao de padres de projeto na reutilizao de cdigo:

Maximiza o trmino do projeto

Facilita manuteno e reutilizao do cdigo
Ajuda no desenvolvimento de grandes projetos em curto prazo agregando
qualidade ao software.
Uso excessivo de padres de projetos pode gerar cdigo confusos e de difcil
utilizao. Contudo, o bom uso destas tcnicas enriquece o software.

Gesto Complexidade
Fato 21
Para cada aumento de 25% do problema, existe 100% de aumento na
complexidade da soluo do software. Isso no uma condio
para tentar mudar (apesar de reduo da complexidade sempre
desejvel uma coisa a fazer); isso apenas a maneira como ela .

Devido a complexidade, aumenta a diversidade;

Existem diferentes abordagens para a concepo correta da soluo de
um problema;
Por que o software tem tantos erros?

Gesto Complexidade
Fato 22
Atravs dos anos, uma controvrsia sobre se o software tem sido um
trabalho trivial e pode ser automatizado, ou se, na realidade, a
mais complexa tarefa compreendida pela humanidade.

O que mais importante em computao: investigao, rigor ou

relevncia;
Maior parte do trabalho do software "rotina".

Ciclo de Vida - Requisitos

Fato 23
Uma das causas mais comuns de projetos fora de controle so
requisitos instveis

Requisito instvel produto do cliente e futuro usurio no ter certeza

sob o problema que deve ser resolvido.
Existem muitos projetos fora de controle no campo do software.
Estimativas fracas ou otimistas de que se vai levar menos tempo e
dinheiro para se construir uma soluo do que ela realmente leva uma
das causas de projetos fora de controle.
Esses projetos esto sem controle desde o incio, no sentido de que o
trabalho est em direo a metas impossveis, e seu "fracasso" mais
uma falha de clculo do que o prprio desenvolvimento do software.

Ciclo de Vida - Requisitos

Fato 23 (continuao)
Uma das causas mais comuns de projetos fora de controle so
requisitos instveis

O produto desenvolvido a partir de requisitos instveis ser uma

soluo que no resolver o problema e, eventualmente, ser
abandonada: todo o tempo e dinheiro gasto para construir a soluo ir
inevitavelmente para o lixo.
Requisitos instveis so uma situao difcil para a equipe de
desenvolvimento, dado que j difcil resolver um problema conhecido
via software.
quase impossvel resolver um problema cujo requisito sempre muda:
esse tipo de situao tambm leva a projetos fora de controle.
Caso clssico desse tipo de problema foi o Aeroporto de Denver-EUA
(Glass 1998). As mudanas de requisitos foram to profundas que
eventualmente todo o trabalho foi desmantelado.

Ciclo de Vida - Requisitos

Fato 23 (continuao)
Uma das causas mais comuns de projetos fora de controle so
requisitos instveis

Como lidar com requisitos instveis?

No incio, acredita-se que o problema estava na fraca gesto de
software
A soluo foi a de manter a forma original dos requisitos. Com o
software pronto o cliente e/ou usurio tinham apenas que aceitar a
soluo.
Nesta poca os cientistas da computao vieram com a noo de
especificaes formais, uma rgida forma matemtica de representar os
requisitos.

Ciclo de Vida - Requisitos

Fato 23 (continuao)
Uma das causas mais comuns de projetos fora de controle so
requisitos instveis

Essa abordagem realmente no funcionou muito bem. A eventual

soluo no resolvia os problemas de usurios/clientes que deveria
resolver.
Eventualmente, essas solues foram abandonadas: todo o tempo, o
dinheiro gasto e as especificaes de requisitos rgidas matemticas
foram para o lixo.
Com muita freqncia essa foi a relao entre os clientes e equipe de
desenvolvimento.

Ciclo de Vida - Requisitos

Fato 23 (continuao)
Uma das causas mais comuns de projetos fora de controle so
requisitos instveis

As equipes de desenvolvimento perceberam que deveriam tolerar o

problema da mudana de requisitos. Vrias abordagens foram tentadas.
Se o problema era levar os requisitos estabilidade, a soluo foi a
prototipagem. Constri-se uma amostra e deixa que o usurio a valide.
O envolvimento do usurio com o desenvolvimento do software ficou
mais intenso.
A idia de prototipagem e envolvimento do usurio continua sendo
utilizada nos dias de hoje, especialmente quando os requisitos so mal
compreendidos.

Ciclo de Vida - Requisitos

Fato 23 (continuao)
Uma das causas mais comuns de projetos fora de controle so
requisitos instveis

Mudanas de requisitos acarretam a mudanas no projeto, nos termos e

condies: funcionalidades novas ou mudanas implicam em mais
tempo e dinheiro em relao ao projeto inicial.
A XP, para resolver o problema de requisitos instveis, diz que um
representante da comunidade dos usurios deve ficar junto da equipe
de desenvolvimento.
Esta presena constante certamente ter impacto em detectar e corrigir
rapidamente qualquer requisito invlido.

Ciclo de Vida - Requisitos

Fato 23 (continuao)
Uma das causas mais comuns de projetos fora de controle so
requisitos instveis

Problemas relacionados:
A) as empresas estaro dispostas a ceder pessoal de forma integral
para compor a equipe de desenvolvimento?
B) Um representante ter capacidade de expor todos os diferentes
pontos de vista dos clientes/usurios?
CONTROVRSIA:

As pessoas concordam que os requisitos mudam e que devem ser tolerados,

porm no h unanimidade de como gerenciar essa mudana.
Mtodos formais X prtica = teoria e prtica no esto se comunicando bem.

Ciclo de Vida - Requisitos

Fato 24
Erros de requisitos so os mais caros de se corrigir quando
encontrados em fase de produo. mais barato a correo
precoce, antes do desenvolvimento.

CONTROVRSIA:

Para o autor, no existe uma controvrsia, porm existem diferentes formas de se

fazer:
Cientistas da computao com suas especificaes tcnicas formais.
Desenvolvedores com avaliao dos requisitos.
Testadores e profissionais de garantia de qualidade exigiria requisitos testveis
e construo de casos de teste.
Analistas de sistemas poderiam exigir abordagens de modelagem.
A XP defende a colocao de um representante do cliente na equipe de
desenvolvimento.

Ciclo de Vida - Requisitos

Fato 25
Requisitos esquecidos so os erros de requisitos mais difceis de se
corrigir.

Como pode faltar um requisito?

Porque requisitos esquecidos difcil de se corrigir?

Levantamento de requisitos , freqentemente, uma interao humana, passveis

de falhas.
O potencial para no recolher requisitos importantes estar sempre presente.
Cada requisito contribui para o nvel de dificuldade de resolver um problema. A
interao entre os requisitos aumenta a complexidade da soluo do problema.

Porque um requisito esquecido difcil de se detectar e corrigir?

Como o requisito no est presente ele no foi implementado e nem testado,

assim a maioria das abordagens bsicas de remoo de erro falhar para
deteco de sua ausncia.

Ciclo de Vida - Projeto

Fato 26
Quando se passa dos requisitos para o projeto, h uma exploso de
novos requisitos causados pela complexidade do processo de
soluo. A lista desses requisitos de projeto geralmente 50 vezes
maior do que a lista de requisitos originais

Porque acontece a exploso de requisitos?

Porque difcil implementar requisitos rastreveis?
Rastreabilidade a capacidade de rastrear um elemento do projeto a
outros elementos em que h relao, especialmente aqueles
relacionados a requisitos
A rastreabilidade pode se tornar complexa

Ciclo de Vida - Projeto

Fato 26 (continuao)
Quando se passa dos requisitos para o projeto, h uma exploso de
novos requisitos causados pela complexidade do processo de
soluo. A lista desses requisitos de projeto geralmente 50 vezes
maior do que a lista de requisitos originais

Com a rastreabilidade possvel:

Gerenciar o escopo de um projeto de software

Gerenciar mudanas nos requisitos
Avaliar o impacto da mudana de um requisito no projeto
Verificar se todos os requisitos do sistema so desempenhados pela
implementao
Verificar se o aplicativo faz apenas o que era esperado que ele fizesse

Um software que faz essa gerncia o IBM Rational RequisitePro

Ciclo de Vida - Projeto

Fato 27
H raramente a melhor soluo de projeto para um problema de
software

A grande maioria de problemas de software podem ser resolvidos de

muitas maneiras diferentes
E extremamente difcil definir a melhor soluo, ou mesmo se h uma
Dado um problema, projetistas no vem a mesma soluo
Vises do XP sobre uma melhor soluo do projeto:

A soluo deve ser to simples quanto possvel (embora em muitos problemas

no haja uma soluo simples)
Se no h nenhuma melhor soluo do projeto, ento a soluo simples ser,
provavelmente, to bem sucedida quanto qualquer outra
O mais simples nem sempre o mais fcil e tambm no escrever menos
cdigo. Simplicidade significa codificar o necessrio para que um requisito seja
atendido e entregue ao cliente

Ciclo de Vida - Projeto

Fato 28
O projeto um processo complexo, iterativo. A soluo inicial do
projeto estar provavelmente errada e certamente no muito boa

Sendo um projeto complexo, ficar tentando chegar ao projeto ideal pode

no ser possvel ou talvez financeiramente no faa valer pena
Tem-se que buscar o projeto que tenha o melhor custo-benefcio e que
tenha as condies de lidar com todos os problemas simultaneamente

Ciclo de Vida - Codificao

Fato 29
Se o arquiteto e o programador tm nveis de conhecimentos
diferentes, haver dificuldade na execuo do projeto

Se o arquiteto for muito detalhista e o programador experiente, este

tender a ignorar a documentao. Ao passo que se o arquiteto for
pouco detalhista e o programador pouco experiente, este ter bastante
dificuldade em codificar
As empresas no discutem esse tipo de problema. Talvez seja por no
passar por essa situao, ou por terem projetos pequenos demais
Tende a ocorrer mais em projetos grandes, no estando vinculado a
diviso de tarefas em si, mas sim devido a reduo de custos

Ciclo de Vida - Codificao

Fato 30
Cobol ruim, mas as outras linguagens so piores

Na dcada de 50, as linguagens eram especficas para cada domnio

Fortran para aplicaes cientficas

bem provvel que as outras linguagens sejam piores porque no

atingiram a "quantidade de usurios" que o Cobol possui
H muito preconceito com Cobol. o "patinho feio" do mundo da
computao, mas o fato que seu uso continua

Ciclo de Vida Remoo de Erros

Fato 31
Remoo de erros a fase mais demorada na construo de
software

Essa a fase de surpresas

As outras fases do ciclo de vida so de certa forma mensurveis,
parcialmente previsveis
Ao longo dos anos estima-se que o esforo em cada fase do processo
de desenvolvimento de software seja a seguinte:

20% levantamento de requisitos

20% design
20% codificao
40% remoo de erros

Ciclo de Vida Testes

Fato 32
Software que um programador tpico acredita estar totalmente testado
tem apenas de 55% a 60% de sua lgica testada. Usando
mecanismos automatizados de teste este nmero pode subir para
85% a 90%. praticamente impossvel testar 100% de um software

Tipos de Testes

Os requisitos foram atingidos?

Todas as partes do software funcionam corretamente?
Comportamento do software para valores aleatrios
Riscos primrio foram tratados?

Pouca ou quase nenhuma ateno a esta fase do ciclo de vida do

software
Geralmente deixada para o final do ciclo de vida, onde no se tm
mais muito tempo (ou nenhum) e o oramento j est terminando (ou
terminado)

Ciclo de Vida Testes

Fato 33
Mesmo que 100% do software fosse testado, isto no garantiria que
ele fosse livre de erros. Aproximadamente, 35% de erros aparecem
pela ausncia de uma lgica e 40% de uma combinao lgica
nica, que no estariam cobertas por um software 100% testado

Testes Estruturais

H um grande nmero de erros que testes estruturais no conseguem detectar

Duas classes de erro que no podem ser detectados:

Erros de omisso de lgica

Situaes de combinaes nicas

Descrena nos resultados dos indivduos envolvidos nos testes

Ciclo de Vida Testes

Fato 34
quase impossvel fazer um bom trabalho de remoo de erros sem
o uso de ferramentas apropriadas. Debuggers so comumente
utilizados, mas outras ferramentas no

Diferente importncia dada as fases do ciclo de vida de um software

Fases de front-end so amplamente divulgadas e valorizadas

Existem centenas de ferramentas para serem utilizadas nessas fases
Cursos especficos para estas fases so encontrados
Situao diferente nas fases de back-end
Poucas ferramentas, pouco conhecidas e pouco utilizadas
O trabalho nesta fase pouco valorizado

Mesma fora que tornam as fases back-end pouco interessantes, as

tornam pouco visveis

Ciclo de Vida Testes

Fato 35
Testes automatizados podem e devem ser realizados. Porm, existe
uma grande quantidade de testes que no devem ser
automatizados

Sonho em poder ter tudo automatizado

Fases que no podem ser automatizadas

Ferramentas automatizadas de gerao de cdigo fonte

Muitos acreditam que tudo pode ser automatizado na etapa de testes. Isto no
verdade
Seleo do que precisa ser testado e como faz-lo
Tipo de teste a ser utilizado
Maneira de conduzir o teste
Conferncia e anlise de resultados

A onda da generalizao pode ser conduzida por vendedores de

ferramentas

Ciclo de Vida Testes

Fato 36
Programadores acostumados a debugar cdigo so um importante
complemento para a etapa de teste no ciclo de vida de um software

A utilizao de apenas ferramentas automatizadas de testes em

projetos de software pode ser um erro
Existem remdios caseiros que so muitas vezes necessrios e
recomendados
O processo de debug o Sherlock Holmes da histria da programao
Inserir cdigos em um programa para verific-lo e test-lo pode ser
contra-produtivo, mas s vezes, necessrio
Muitos programadores utilizam de suas tcnicas quase intuitivamente

Ciclo de Vida Revises e Inspees

Fato 37
Quando se realiza inspees rigorosas, 90% dos erros do software
poderiam ser removidos antes do primeiro caso de teste

Custo das inspees inferior ao custo dos testes que seriam

necessrios para encontrar os mesmos erros
A inspeo parece ser algo perfeito por que no fazer uso dela ento?

H poucas pessoas que ganham dinheiro fazendo inspees, no h

metodologias inovadoras
No ciclo de vida de um software inspees so vistas como algo invisvel, algo
que acontece no final
Atividade esgotante e rdua, necessita de organizao e rigor

Raramente sabemos quantos erros um produto tem, ento como relatar

que com o uso das inspees at 90% dos erros so detectados?

Ciclo de Vida Revises e Inspees

Fato 38
Apesar dos benefcios de uma reviso rigorosa, os testes no devem
ser descartados

A reviso de cdigo uma potente tcnica, porm no suficiente para

fazer um trabalho completo de eliminao de erros
Remoo de erros uma tarefa complexa, em que se exigido mais do
que reviso

No importa o quanto a inspeo seja bem feita, essa no pode ser a

nica tcnica a ser seguida para a eliminao dos erros

Ciclo de Vida Revises e Inspees

Fato 39
As opinies so importantes tanto do ponto de vista do cliente quanto
do ponto de vista do processo de melhoria. Muitas organizaes no
fazem ou no coletam opinies

Falta comunicao para discutirem os erros que vivenciaram

Lies aprendidas sobre um projeto tendem a ser descartados, devido a
correria que imposta
No documentam os problemas vividos

Na corrida pelo novo existe uma tendncia de descartarem coisas

antigas

Ciclo de Vida Revises e Inspees

Fato 40
Revisar cdigo no algo simples, pois mexe com o ego das pessoas
e isso pode tornar um processo desastroso

Desenvolver cdigo e entregar para outra pessoa revis-lo, pode gerar

brigas, pois muitos pontos so subjetivos
Necessidade de ter rigor e seriedade no momento da reviso, exigindo
dedicao total dos participantes
Para criar um ambiente mais agradvel todas as pessoas envolvidas
deveriam reunir e discutirem tudo que poderia ser melhorado

Ciclo de Vida Manuteno

Fato 41
Manuteno geralmente consome de 40% a 80% (em mdia 60%)
dos custos de um software. Por isso , provavelmente, a fase mais
importante do ciclo de vida

Manuteno

Softwares

Reparar algo quebrado ou desgastado

Podem ser modificados para fazerem coisas diferentes
Podem ter erros (quando construdos ou modificados)

Manuteno pode ser cara e consumir muito tempo , por isso a parte mais
importante do ciclo de vida
Inesperado mesmo para profissionais de informtica que tendem a acreditar que, uma
vez colocados em produo, passam anos ou dcadas sem serem incomodados

Exemplo: Y2K (Bug do milnio)

Desenvolvedores no se
desenvolvimento inicial.

atm

manuteno,

concentrando-se

apenas

no

Ciclo de Vida Manuteno

Fato 42
Aprimoramento responsvel por 60% do custo de manuteno.
Correo de erro, 17%. Ento, manuteno muito mais adicionar
funcionalidades a um software antigo do que corrigir erros deste

60% dos valores de manuteno so gastos em modificaes

Modificaes:

Software funcional Aprimoramento

Muito tempo gasto em novos requisitos
Coisas que os produtos devem fazer mas no foi levado em considerao durante o
desenvolvimento
Requisitos deixados de lado durante o desenvolvimento

Feedback
Mudanas em um produto existente sempre so complicadas
Regra 60/60 Dos 60% gastos em manuteno, 60% so gastos em
aprimoramentos

Experts sugerem que os custos de manuteno de software , primeiramente, correo

de erros.

Ciclo de Vida Manuteno

Fato 43
Manuteno a soluo, no o problema

Muitos vem a manuteno como um problema, algo para ser reduzido

Pode ser um problema, caso seja exclusivamente correo de erros
Ns criamos essa coisa, mas agora precisamos que faa algo um
pouco diferente
Fazer mudanas em software no uma coisa trivial, porm, mais
fcil e simples que em produtos tangveis

"Manuteno um problema falsamente simples

Ciclo de Vida Manuteno

Fato 44
Muitas tarefas do desenvolvimento e da manuteno so
similares, exceto para tarefas de adicionar ao produto
funcionalidade que no esto compreendidas neste. Como
essas tarefas so dominantes, possvel afirmar que a
manuteno uma tarefa mais difcil que o desenvolvimento

Apenas nuances diferenciam as fases de manuteno e desenvolvimento

Projetar uma soluo dentro do contexto de um produto j projetado

Sem dvidas uma das partes mais complicadas

Pesquisas mostram que entender produtos existentes a parte mais difcil da
manuteno

A engenharia reversa mais complicada que o projeto original

Requisitos novos gerados

Se carem bem, as modificaes podem ser simples

Seno, podem ser complicadas ou mesmo impossveis

Existe pouca controvrsia sobre esse fato, porm muita descrena

Ciclo de Vida Manuteno

Fato 45
Melhor uso da engenharia de software conduz a mais
manuteno, no a menos

Sistemas desenvolvidos com modernas tcnicas de desenvolvimento

requerem mais tempo de manuteno
Necessidade de um tempo maior, devido as acrscimo de modificaes
realizadas
Mais modificaes tendem a ocorrer, devido a maior facilidade em
realiz-las

Poucas pessoas esto cientes desse fato. Se estivessem, seria

extremamente controverso. Esta controvrsia poderia ser extremamente
saudvel, uma vez que foraria a explorao de algumas verdades.

Qualidade
Qualidade de Software

Qualidade um termo muito amplo

No h consenso sobre sua definio, quem o responsvel por ela, ou
como possvel medi-la
Carter mais tcnico do que de gerenciamento

Qualidade
Fato 46
Qualidade um conjunto de atributos

Os atributos no possuem ordem de importncia definida, o que varia de

acordo com a necessidade de cada projeto e com a filosofia da empresa
1.

PORTABILIDADE O software pode ser facilmente utilizado em diferentes plataformas.

2.

CONFIABILIDADE O software atende aos requisitos e apresenta o mnimo possvel de erros

3.

EFICINCIA O software economiza no consumo de tempo de execuo e espao de

armazenamento

4.

USABILIDADE O software fcil e confortvel de ser usado, do ponto de vista do usurio

5.

TESTABILIDADE

O software pode ser facilmente testado

Ajuda a aumentar a confiabilidade do produto

COMPREENSIBILIDADE O software pode ser facilmente compreendido por aqueles que faro sua
manuteno cdigo-fonte, interface, documentao etc.
MODIFICABILIDADE

O software pode ser facilmente modificado pelos desenvolvedores que faro sua manuteno

Relacionado diretamente compreensibilidade

Qualidade
Fato 47
Qualidade no a satisfao do usurio, o preenchimento
dos requisitos, o cumprimento do cronograma de metas
e custos, ou a confiabilidade

Muitos julgam que a satisfao do usurio a juno dos seguintes

fatores:

Preenchimento de requisitos
Entrega dentro do prazo especificado
Custo apropriado
Qualidade do produto

A qualidade um dos itens que definem a satisfao, mas no o nico

Qualidade deve envolver os aspectos tcnicos, no os subjetivos

Qualidade - Confiana
Fato 48
Existem erros que a maioria dos programadores tendem a
cometer

Programadores = seres humanos tudo mundo erra;

N-verses
Equipes diferentes geram erros diferentes = normal.
Equipes diferentes gerando os mesmos erros = tendenciosos software
cria sua prpria armadilha.

Qualidade - Confiana
Fato 49
Erros tendem a aglomerar-se

Metade dos erros so encontrados em 15% dos mdulos

80% de todos os erros so encontrados em apenas 20% dos mdulos
"Cerca de metade dos mdulos so livres de erro
O fato que grande parte dos erros esto agrupados nos softwares:

Parte desses programas so mais complexas que outras

A qualificao dos programadores que formam a equipe Melhores
programadores so 28 vezes mais qualificados.
Concluso: se voc encontrar um nmero de erros maior que o esperado em um
mdulo, muito provavelmente havero mais.

Qualidade - Confiana
Fato 50
No existe uma abordagem na remoo de erros que seja
a melhor

No existe bala de prata para remoo de erros

Nenhum mtodo existente capaz de remover ou localizar todos os
erros.
Controvrsias so alimentadas por cada nova tcnica ou ferramenta
que surge prometendo resolver todos os problemas.

Qualidade - Confiana
Fato 51
Erros residuais sempre existiro. A meta deve ser
minimiz-los ou eliminar os erros graves

Pessimistas afirmam que sempre existiro erros residuais,

independente do processo.
Otimistas acreditam que, com um processo rgido, possvel criar um
software livre de erros.
Boehm e Basili (2001, IEEE Computing) afirmam que prticas
disciplinadas podem reduzir a introduo de defeitos em at 75%.

Qualidade - Eficincia
Fato 52
Eficincia deriva mais de um bom projeto do que de uma
boa codificao

Programadores tendem a acreditar que a boa codificao o caminho

para um produto eficiente.
As ineficincias vm, entre outros, de entrada e sada de dados,
interfaces desorganizadas e desperdcio de tempo interno.

Qualidade - Eficincia
Fato 53
Cdigo em Linguagem de Alto Nvel (HOL - High Order
Language), otimizado de forma adequada pelo
compilador, pode ser at 90% to eficiente quanto o
cdigo em Assembler, ou mesmo superior, em algumas
arquiteturas modernas mais complexas

Este fato foi confirmado em um estudo sobre software para aplicaes

avinicas, publicado por Raymond Rubey (1978, Higher Order
Languages for Avionics Software).
Os seguintes resultados foram divulgados neste estudo:

Comparado ao Assembler, a ineficincia da HOL nas aplicaes avinicas ficou

entre 10% e 20% em quase todos os relatrios.
Otimizao de um cdigo HOL pode deix-lo at 10% mais eficiente, enquanto no
Assembler, este ndice fica entre de 2% e 5%.

Qualidade - Eficincia
Fato 53 (continuao)
Cdigo em Linguagem de Alto Nvel (HOL - High Order
Language), otimizado de forma adequada pelo
compilador, pode ser at 90% to eficiente quanto o
cdigo em Assembler, ou mesmo superior, em algumas
arquiteturas modernas mais complexas

Vantagem da HOL

Menos linhas de cdigo para resolver problemas;

Cdigo pode ser portvel;
Mais fcil de ser mantido (entendido e alterado);
Pode ser facilmente re-estruturado para aumentar a eficincia;
Pode ser escrito por programadores menos habilidosos;
Compilador pode otimizar o uso de arquiteturas modernas (como pipeline e
cache);

Qualidade - Eficincia
Fato 54
Existe uma relao de troca mtua entre otimizao de
tamanho e de tempo. Geralmente, uma melhoria em um
degrada o outro

Um exemplo:

Java muito eficiente em termos de tamanho, mas no to eficiente em termos de

tempo.
Como o Java no compilado em linguagem de mquina, deve ser interpretado
enquanto executado, aumentando muito o tempo de execuo.

So poucos os casos em que cdigo eficiente em tempo tambm resulta na

eficincia em tamanho.
Eficincia em tamanho mais fcil de mensurar do que eficincia em tempo.
Se voc busca pelo atributo de qualidade chamado eficincia, tenha em
mente que tipo de eficincia mais importante.

Pesquisa
Fato 55
Muitos pesquisadores de SW defendem mais do que
investigam. Alguns conceitos defendidos valem muito menos
que seus defensores acreditam. Existe uma escassez de
pesquisa avaliativa para ajudar a definir qual o real valor de
alguns conceitos

Pesquisa avaliativa:

Importncia da pesquisa:

Identifica, valida e difunde mtodos, modelos, ou teorias;

A prtica depende profundamente da teoria para ajudar no entendimento de quais so
as novas tecnologias que trazem grande benefcio e diminui a influncia dos formadores
de opinio que induzem as pessoas a investirem em treinamentos, de novos conceitos,
que no respondem ao que esperado deles, ou pior, sugerem solues que nem eles
mesmos sabem se resolvem totalmente um problema.

Pesquisa avaliativa no contexto da TI:

Engenharia de Software 14%

Cincia da Computao 11%
Sistemas de Informao 50%