Introduo a

Engenharia de Software
Viviane Torres da Silva
viviane.silva@ic.uff.br
http://www.ic.uff.br/~viviane.silva/2012.1/es1

Histrico

1968: Crise do Software
Nasce a Engenharia de Software

1970s:
Lower-CASE tools (programao, depurao, colaborao)
Ciclo de vida cascata
Desenvolvimento estruturado

1980s:
Ciclo de vida espiral
Desenvolvimento orientado a objetos

1990s: Upper-CASE tools

Processos
Modelagem

Atualmente

Mtodos geis

Desenvolvimento dirigido por modelos

Linhas de produto

Experimentao

Engenharia de Software para outros paradigmas
Agentes de Software

Elementos da ES

Mtodo, Processo e Ferramenta

Elementos da Engenharia de Software

Elementos da Engenharia de Software

Processo
Define os passos gerais para o desenvolvimento e manuteno do
software
Serve como uma estrutura de encadeamento de mtodos e
ferramentas

Mtodos
Descrevem como fazer um passo especfico do processo
So os how tos

Ferramentas
Automatizam / auxiliam o processo e os mtodos

Elementos da Engenharia de Software

O que processo, mtodo ou ferramenta?
1. Coloque em uma panela funda o leite condensado, a
margarina e o chocolate em p.
2. Cozinhe [no fogo] em fogo mdio e mexa sem parar com
uma colher de pau.
3. Cozinhe at que o brigadeiro comece a desgrudar da panela.
4. Deixe esfriar bem, ento unte as mos com margarina, faa
as bolinhas e envolva-as em chocolate granulado.

Elementos da Engenharia de Software

O que processo, mtodo ou ferramenta?
1. Coloque em uma panela funda o leite condensado, a
margarina e o chocolate em p.
2. Cozinhe [no fogo] em fogo mdio e mexa sem parar com
uma colher de pau.
3. Cozinhe at que o brigadeiro comece a desgrudar da panela.
4. Deixe esfriar bem, ento unte as mos com margarina, faa
as bolinhas e envolva-as em chocolate granulado.
Processo

mtodo
ferramenta

Elementos da Engenharia de Software

Cuidado com o desenvolvimento guiado por ferramentas
importante usar a ferramenta certa para o problema
O problema no deve ser adaptado para a ferramenta disponvel

Para quem tem um martelo, tudo parece

prego

Cuidado ao escolher o processo, o mtodo e a ferramenta

Muito ajuda quem no atrapalha

No existe o melhor processo, mtodo ou ferramenta

Depende da equipe, do projeto, da empresa, ....

Processos implcitos x explcitos

Lembrem-se: Processos sempre existem, seja de forma
implcita ou explcita!
Processos implcitos so difceis de serem seguidos, em especial por
novatos
Processos explcitos estabelecem as regras de forma clara

Processos estveis x capazes

Nem sempre o processo mais rpido um processo estvel
ou capaz

Problema:
Ir em at 20 minutos de Icara para So Francisco

Processos

Ir de carro
Ir de nibus
Ir de bicicleta
Ir a p

Qual o processo mais rpido num cenrio timo?

Quais processos so estveis?

Quais processos so capazes?

Processos estveis x capazes

nibus

probabilidade

probabilidade

carro

tempo

tempo

20 min

bicicleta

probabilidade

probabilidade

a p

20 min

tempo

20 min

tempo

20 min

Modelos de Maturidade

Mtrica de Qualidade

Modelos de Maturidade

A qualidade do produto est intimamente ligada qualidade
do processo

Um modelo de maturidade uma coleo estruturada de
elementos que descrevem certos aspectos da maturidade de
uma organizao

Servem para guiar empresas na busca por qualidade

No determinam como algo deve ser feito (no uma
metodologia), mas sim o que deve ser feito (melhores
prticas)

Principais modelos em uso no Brasil
CMMI (Capability Maturity Model Integration)
MPS.BR

CMMI

CMMI uma evoluo do CMM para estabelecer um modelo
nico

CMM (Capability Maturity Model) tem como objetivo
estabelecer com base em estudos, histricos e
conhecimento operacional um conjunto de "melhores
prticas para diagnstico e avaliao de maturidade do
desenvolvimento de softwares em uma organizao

O CMM fornece s organizaes orientao sobre como
ganhar controle do processo de desenvolvimento de software
e como evoluir para uma cultura de excelncia na gesto de
software.

CMMI

22 duas reas de processo:

Gerncia de Configurao (controle da manuteno),
Planejamento de Projeto (planifica tempo e custo do projeto),
Validao e verificao de software (Estamos construindo o produto
certo?, Estamos construindo certo o produto?)
...

5 nveis de maturidade

CMMI Nveis

I/III

Nvel 1: inicial (ad-hoc)

Nenhum processo implementado formalmente
O software desenvolvido de maneira improvisada (ad-hoc)

Nvel 2: gerenciado
Projeto executado de acordo com o planejado quando as etapas so
seguidas
Foco no gerenciamento bsico do processo
Gerncia de requisitos
Planejamento do projeto
Monitorao e Controle do projeto
Gerncia de Acordos com Fornecedores
Garantia da Qualidade do Processo e do Produto
Medio e Anlise
Gerncia de configurao

CMMI Nveis

II/III

Nvel 3: definido (padronizao do processo)

Processo descrito em forma de padres, procedimentos, mtodos

Foco na padronizao do processo organizacional
Definio do processo organizacional
Treinamento organizacional
Gerncia integrada do projeto
Desenvolvimento de Requisitos
Soluo Tcnica
Integrao do Produto
Verificao
Validao
Gerncia de Riscos
Anlise de Deciso e Resoluo

CMMI Nveis

IIII/III

Nvel 4: gerenciado quantitativamente

Medio e controle do processo

Foco no controle quantitativo do processo
Gerncia quantitativa do processo
Desempenho do Processo Organizacional

Nvel 5: otimizado
Foco na melhoria contnua do processo
Implantao de Inovaes na Organizao
Anlise de Causas e Resoluo

MPS.BR

Modelo brasileiro semelhante ao CMMI
Foco nas pequenas e mdias empresas brasileiras
Menor custo para implementao e avaliao
Mais degraus intermedirios, ajudando na melhoria progressiva

Modelo com 19 processos divididos em 7 nveis de

maturidade

Mapeamento para o CMMI

Nvel 5 = A
Nvel 4 = B
Nvel 3 = C
Nvel 2 = F

MPS.BR

Certificao ou melhoria?

Avaliaes CMMI e MPS.BR tem como foco a melhoria
contnua, e no a certificao

Resultado de uma avaliao

Nvel atingido
Pontos fortes
Pontos fracos
Oportunidades de melhoria

Validade de 3 anos

Processo de qualidade

ltima palavra para medir a qualidade de um processo:
Satisfao do Cliente

Outros indicadores importantes
Qualidade dos produtos gerados
Custo real do projeto
Durao real do projeto

Modelos de Ciclo de Vida de

Projeto

Modelos de ciclo de vida de projeto

Existem alguns processos pr-fabricados
Esses processos so conhecidos como modelos de ciclo de vida
Esses processos apresentam caractersticas predefinidas

Devem ser adaptados para o contexto real de uso

Caractersticas do projeto
Caractersticas da equipe
Caractersticas do cliente

Exemplos:

Cascata
Incremental
RAD (Rapid Application Development)
Prototipao
Espiral

Ciclo de vida Cascata

Ciclo de vida Cascata

til quando se tem requisitos estveis e bem definidos
Ex.: Adicionar um novo dispositivo legal em um sistema de
contabilidade

No lida bem com incertezas

Fornece pouca visibilidade do estado do projeto
Muito tempo para a primeira entrega
Dificuldade na obteno de feedback do cliente

Ciclo de vida Incremental

verso final

...

funcionalidades

verso i

verso 1

tempo

Ciclo de vida Incremental

Faz entregas incrementais do software
Cada incremento construdo via um mini-cascata
Cada incremento um software operacional

Verses anteriores ajudam a refinar o plano

Feedback constante do cliente

Diminuio da ansiedade do cliente

O cliente rapidamente recebe uma verso funcional do software

Ciclo de vida RAD (Rapid Application Development)

...

Ciclo de vida RAD

Funcionamento equivalente ao cascata

Principais diferenas
Visa entregar o sistema completo em 60 a 90 dias
Mltiplas equipes trabalham em paralelo na modelagem e construo
Assume a existncia de componentes reutilizveis e gerao de cdigo

Difcil de ser utilizado em domnios novos ou instveis

Prototipao

Prototipao

Usualmente utilizado como auxlio a outro modelo de ciclo de
vida

til para
Validar um requisito obscuro com o cliente
Verificar o desempenho de um algoritmo especfico
Gerenciar o riso do desenvolvimento

Prottipo deveria ser jogado fora no final

Prottipos no so produtos
Usualmente os clientes desejam colocar prottipos em produo

Ciclo de vida Espiral

Planejamento
(anlise de riscos)

Comunicao

Implantao

Modelagem

Construo

Ciclo de vida Espiral

Foco principal no gerenciamento de riscos

A cada ciclo
O conhecimento aumenta
O planejamento refinado
O produto gerado no ciclo anterior evoludo (no jogado fora)

Cada ciclo evolui o sistema, mas no necessariamente entrega

um software operacional

Modelo em papel
Prottipo
Verses do produto
Etc.

O tempo no desenvolvimento pode aumentar mas ocorre a

diminuio dos riscos

Outros ciclos de vida

Mtodos formais
Uso de formalismos matemticos
Alto nvel de complexidade
Usualmente aplicado somente a software crtico

Processo Unificado
Tentativa de obter o que h de melhor em cada modelo de ciclo de
vida

Exerccio

Sua empresa foi contratada para fazer um software para um
cliente. Qual o melhor modelo de ciclo de vida para o caso
abaixo?
a) Este cliente possui os requisitos do produto que deseja muito
bem especificados.
b) Ele deseja receber o produto em etapas, i.e., deseja ver
diferentes verses do produto, e no somente o produto j
finalizado no prazo final de entrega.
c) Sua empresa no est acostumada a desenvolver produtos
para este domnio, por tanto obter feedback do cliente
importante, e cuidado com os riscos no desenvolvimento do
produto.
d) O prazo de entrega do produto de 80 dias

Software x Hardware

Software x Hardware

Software desenvolvido

Alto custo de criao

Baixo custo de reproduo
No enguia, mas deteriora
Defeitos no produto usualmente so conseqncias de problemas no
processo de desenvolvimento

Hardware manufaturado

Alto custo de reproduo

Pode enguiar
Defeitos podem vir tanto da concepo quanto da produo
Pode ser substitudo na totalidade ou em partes

Software x Hardware

Curva de falha de hardware

Taxa de falha

mortalidade infantil

Enguio

tempo

Software x Hardware

Taxa de falha

Curva ideal de falha de software

tempo

Software x Hardware

Taxa de falha

Curva real de falha de software

modificao
tempo

Manuteno

Por que fazer bem feito?

Por que mais barato!
Historicamente, 60% a 80% do esforo total ocorre na manuteno

Por que mais rpido!

No ter tempo para fazer bem feito agora significa ter tempo para
refazer depois

Por que mais fcil!

Desenvolvimento ocorre uma nica vez
Manuteno para sempre

O que a manuteno?

O processo de modificar um sistema de software ou
componente, depois da entrega, para corrigir falhas,
melhorar desempenho ou outros atributos, ou adaptar a
mudanas no ambiente.
IEEE Std 620.12 1990

Desenvolvimento

Release

Manuteno

Quando inicia a manuteno?

Desenvolvimento

Release

Manuteno

Desenv.
Desenv.
Desenv.

Release
Manut.

Release
Manut.

Quais so os tipos de manuteno?

Quais so os tipos de manuteno? --- Correo

Manuteno corretiva
Reativa
Corrige problemas reportados
Faz o software voltar a atender aos requisitos

Manuteno emergencial
No programada
Mantm temporariamente o sistema funcionando
Necessita uma manuteno corretiva posterior

Manuteno preventiva
Pr-ativa
Corrige problemas latentes

Quais so os tipos de manuteno? --- Evoluo

Manuteno adaptativa
Mantm o software usvel aps mudanas no ambiente

Manuteno perfectiva
Prov melhorias para o usurio
Melhora atributos de qualidade do software

Processo de manuteno

Solicitao de
Modificao
Planejamento
Migrao
Anlise

Implementao
Descontinuidade

Reviso

Exerccio:

Aps a sua empresa entregar o produto ao cliente:
O usurio reportou um problema
A empresa detectou possveis geradores de problemas
futuros
A empresa deixou o produto mais seguro

Quais so os tipos de manuteno que precisam ser
realizadas neste software?

Alguns Mitos

Mitos gerenciais

Basta um bom livro de ES para fazer bom software
Um bom livro certamente ajuda, mas ele precisa refletir as tcnicas
mais modernas de ES e ser lido!

Se estivermos com o cronograma atrasado, basta adicionar

mais gente ao projeto
Adicionar gente a um projeto atrasado faz o projeto atrasar mais!
As pessoas que esto entrando tero que aprender sobre o projeto
antes de comear a ajudar no desenvolvimento
As pessoas que esto no desenvolvimento, tero que parar para
explicar aos que esto entrando

Se o projeto for terceirizado, todos os meus problemas esto

resolvidos
mais difcil gerenciar projetos terceirizados do que projetos
internos!

Mitos do cliente

Basta dar uma idia geral do que necessrio no incio
Requisitos ambguos normalmente so uma receita para desastre!
Comunicao contnua com o cliente fundamental!

Modificaes podem ser facilmente acomodadas, porque

software flexvel
O impacto de modificaes no software varia em funo da
modificao e do momento em que ela requisitada!
Comunicao contnua com o cliente fundamental!

Mitos do desenvolvedor I/II

Assim que o cdigo for escrito o trabalho termina
60% a 80% do esforo ser gasto depois que o cdigo foi escrito!
(implantao do sistema, testes, manuteno, ....)
Vale a pena se esforar para chegar a um bom cdigo (boa
documentao, bom projeto, etc.)!

S possvel verificar a qualidade de um software quando o

executvel existir
Revises usualmente so mais eficazes que testes, e podem ser
utilizadas antes do software estar executvel!

Mitos do desenvolvedor II/II

O nico produto a ser entregue em um projeto o cdigo
Alm do cdigo, documentaes tanto para a manuteno quanto
para o uso so fundamentais!

Engenharia de software gera documentao desnecessria

Engenharia de software foca em criar qualidade, e no criar
documentos!
Algum grau de documentao necessrio para evitar retrabalho!
Questione sempre que encontrar um documento desnecessrio para
o projeto!

7 princpios de Hooker

Tem que existir uma razo para se fazer software
Se no for possvel identificar essa razo, melhor no fazer
Fazer software, em ltima instncia, consiste em agregar valor para o
usurio
importante enxergar os reais requisitos do software!

Keep it simple, sir! (KISS)

um projeto deve ser o mais simples possvel, mas no mais simples
que isso
As solues mais elegantes normalmente so simples
Fazer algo simples usualmente demanda mais tempo do que fazer de
forma complexa

7 princpios de Hooker

Mantenha o estilo
O projeto de um software deve seguir um nico estilo (estilo de
codificao, documentao, teste, um mesmo processo, ...)
A combinao de diferentes estilos corretos pode levar a um software
incorreto
Padres e estilos devem ser estabelecidos no incio e seguidos por
todos

O que produzido por voc consumido por outros

Sempre especifique, projete e codifique algo pensando que outros vo
ler
Sempre exija qualidade nos produtos que voc consome e fornea
qualidade nos produtos que voc produz

7 princpios de Hooker

Esteja pronto para o futuro
Sistemas de boa qualidade tm vida longa
Projete desde o incio pensando na manuteno

Planeje para reutilizao

Pense no problema geral, e no s no problema especfico
Busque por solues j existentes

Pense!
plano desnecessrio, mas planejar indispensvel D.
Eisenhower
Avalie alternativas
Detalhe os riscos

Exerccio
Jogo dos sete erros:

A nossa empresa fez o levantamento dos requisitos com o
cliente tentando esclarecer todas as ambigidades.

Aps a fase de levantamento dos requisitos, o projeto passou
para a fase de codificao.

Ao final da codificao e gerao do executvel, o projeto foi
testado.

S aps o teste, a empresa acionou o cliente novamente para
a entrega do cdigo gerado.

Durante a fase de codificao e aps verificar um atraso no
cronograma, mais profissionais foram includos na equipe e
parte do projeto foi terceirizada.

Aps a codificao do produto, toda a equipe foi deslocada
para o desenvolvimento de outro projeto.

Ns precisamos de ES!

Introduo a
Engenharia de Software
Vrias transparncias foram produzidas
por Leonardo Murta
http://www.ic.uff.br/~leomurta