Aspectos Econômicos da Engenharia de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Click to Edit Master Title Style
Click to edit Master subtitle style
*
*
Aspectos Econômicos da Engenharia de Software
A Motivação para o Modelo Iterativo e a Tecnologia de Objetos
Baseado em uma apresentação de Craig Larman
© Nabor C. Mendonça 2001
*
*
Software — Um Investimento de Risco
Resultado de projetos de software realizados nos EUA no início da década de 90
Inacabados
30% 
Concluídos
70%
Fonte: Standish Report, 1994
Todos baseados no modelo cascata.
53% custaram até 200% acima da estimativa inicial.
Estimou-se que $81 bilhões foram gastos em projetos fracassados só no ano de 1995.
© Nabor C. Mendonça 2001
*
*
O Que Deu Errado?
O modelo cascata é fortemente baseado em suposições oriundas dos processos de engenharia convencionais 
Algumas dessas suposições não foram confirmadas na prática
Todos os requisitos podem ser precisamente identificados antes do desenvolvimento
Os requisitos são estáveis 
O projeto pode ser feito totalmente antes da implementação
© Nabor C. Mendonça 2001
*
*
Imprecisão dos Requisitos
Estudo publicado por Capers Jones em 1987, baseado em 6.700 sistemas
0
10
20
30
40
50
60
10
100
1000
10000
100000
Tamanho do Projeto em Pontos por Função
% de Req's Problemáticos
© Nabor C. Mendonça 2001
*
*
Instabilidade dos Requisitos
O mercado muda — constantemente
As tecnologias mudam — inevitavelmente
A vontade e objetivos dos usuários mudam — imprevisivelmente 
© Nabor C. Mendonça 2001
*
*
Projeto Completo antes da Implementação?
Pergunte a qualquer programador
Requisitos são incompletos e instáveis
Uma especificação completa tem que ser tão detalhada quanto o próprio código
Desenvolver software é uma atividade intrinsecamente “difícil”
Discover Magazine, 1999: Software caracterizado como a mais complexa “máquina” que a humanidade já construiu
© Nabor C. Mendonça 2001
*
*
Esforço — O Perigo dos Passos Largos
Fonte: Applied Software Measurement, Capers Jones, 1997
© Nabor C. Mendonça 2001
*
*
Produtividade — O Perigo dos Passos Largos
0
500
1000
1500
2000
2500
3000
3500
4000
4500
1
10
100
1000
Tamanho do Projeto em KLOC
LOC/Pessoa por Mês
Fonte: Measures For Excellence, Putnam, 1992. Baseado em 1.600 sistemas 
© Nabor C. Mendonça 2001
*
*
A Voz da Experiência e da Pesquisa
Em 1994, o DoD (EUA) parou de contratar projetos baseado no modelo cascata, por causa de fracassos abismais
Eles agora incentivam um modelo iterativo
Virtualmente todos os trabalhos na área publicados nos últimos 5 anos defendem a substituição do modelo cascata por um modelo iterativo
The Unified Software Development Process
Applying UML and Patterns
Software Project Management
Succeeding with Objects
Object Solutions
Surviving Object-oriented Projects
…
© Nabor C. Mendonça 2001
*
*
Portanto...
© Nabor C. Mendonça 2001
*
*
Usem o Modelo Iterativo!
Passos curtos, feedback e refinamento
Iterativo, incremental, com intervalos de tempo (ciclos) pré-estabelecidos
Iteração
1
Projeto
Codificação, Teste,
Integração
Análise
...
Iteração
2
Projeto
Análise
Codificação, Teste,
Integração
2 semanas
2 semanas
© Nabor C. Mendonça 2001
*
*
Um Processo Iterativo Popular — RUP
Atenção: as fases não são iterações!
© Nabor C. Mendonça 2001
*
*
O Custo da Mudança
Planos estratégicos e racionais de desenvolvimento baseiam-se no custo total do sistema, não apenas nos custos de desenvolvimento
Documentação
Projeto
Teste
Código
Outros
Revisão & 
Manutenção
Fonte: DP Budget, Vol. 7, No. 12, Dez. 1988
© Nabor C. Mendonça 2001
*
*
O Custo da Mudança
Estudo com projetos de software do governo Americano
Entregue
mas nunca
usado
satisfatoriamente
47% 
Usado mas
bastante
alterado ou
em seguida
abandonado
19% 
Pago mas 
não entregue
29% 
Usado depois
de alterações
3% 
Usado tal como
entregue
2% 
Fonte: US Government Accounting Office, Report FGMSD-80-4
© Nabor C. Mendonça 2001
*
*
O Custo da Mudança
Um estudo da AT&T indicou que, na média,
© Nabor C. Mendonça 2001
*
*
Por que a Tecnologia de Objetos?
Os principais problemas do software hoje são 
Diminuir o custo e o tempo da mudança
Aumentar a capacidade e facilidade de adaptação
Fato: Objetos são especialmente bons para 
Reduzir o tempo necessário para adaptar um sistema existente (reação mais rápida à mudanças no seu ambiente de negócio)
Reduzir o esforço, a complexidade e os custos associados à mudança
Em suma:
© Nabor C. Mendonça 2001
*
*
E Reuso?
Segundo um estudo corporativo de 1997, as razões prioritárias para se adotar a TO são: 
1. Capacidade de aproveitar novas plataformas e ferramentas
2. Facilidade de manutenção
3. Economia de custos
4. Desenvolvimento de aplicações lucrativas 
5. Encapsulamento das aplicações existentes
6. Melhores interfaces
7. Maior produtividade
8. Participação no "futuro da computação"
9. Prova da capacidade de usar a tecnologia
10. Rápido desenvolvimento de aplicações estratégicas 
11. Reuso de software
Notem a baixa prioridade
Notem a alta prioridade
© Nabor C. Mendonça 2001
*
*
E Reuso?
Reuso é um objetivo nobre e válido, mas o verdadeiro poder da TO está na sua capacidade de suportar sistemas facilmente adaptáveis
Infelizmente, reuso é muito difícil na prática, e mesmo organizações especializadas em TO tiram pouco proveito dele
As questões são mais organizacionais do que técnicas
© Nabor C. Mendonça 2001
*
*
E Reuso?
As pesquisas não mostram nenhum relacionamento entre maior reuso e a coleta de bibliotecas de componentes reusáveis de projetos anteriores 
Communications of the ACM, pp 75-87 June, 1995
http://ite.gmu.edu/~nnada/pap.html
Reuso não é sempre obtido ou compensador no nível de objeto
O foco deve estar em:
Fatores organizacionais para suportar reuso 
Criação e uso de frameworks
Reuso de arquiteturas e padrões de análise e projeto
© Nabor C. Mendonça 2001
*
*
Reuso a Nível de Framework
Onde as organizações especializadas na TO conseguem obter reuso? 
Com frameworks
Porém, a criação de frameworks eficazes requer:
Projetistas e programadores bastante habilidosos
© Nabor C. Mendonça 2001
*
*
Por que a Tecnologia de Objetos?
Uma outra razão não-técnica, mas não trivial é. . .
A capacidade de atrair e reter profissionais de talento
A TO é indiscutivelmente a “tecnologia quente” para o futuro, e organizações que desenvolvem software não conseguirão atrair e reter talentos se não a usarem
© Nabor C. Mendonça 2001
*
*
Por que a Tecnologia de Objetos?
As organizações normalmente iniciam a adoção pensando que a TO levará a um menor tempo de desenvolvimento, maior reuso, e maior produtividade
Infelizmente, isto nem sempre acontece
Porém, elas acabam descobrindo algo útil e poderoso. . .
“It takes complexity to manage complexity”
R. Martin, Editor do C++ Report, co-autor de Object-Oriented Analysis and Design, com Grady Booch
© Nabor C. Mendonça 2001
*
*
Por que a Tecnologia de Objetos?
Ataca complexidade elegantemente e gera fácil adaptabilidade
. . . 
Produtividade
Reuso
A produtividade se sobressai nas fases de manutenção ou modificação do sistema — freqüentemente com mudanças profundamente mais rápidas, se o sistema foi habilidosamente projetado.
“O valor da TO (APOO, POO) está fundamentalmente na sua capacidade de lidar com problemas complexos e criar sistemas compreensíveis e gerenciáveis, que podem acompanhar uma complexidade crescente e ser facilmente adaptáveis—se habilidosamente projetados.”
						Craig Larman
© Nabor C. Mendonça 2001