1

Gestão de DesejosEngenharia de Software numa empresa

certificada de Telecomunicações

José BonnetFCUP, 2003.Mai.19

2

Índice de conteúdos

• Introdução• O problema• A solução• Conclusão

3

Onde estamos ...

4

Como nos organizamos ...

5

A nossa qualidade ...

•34 colaboradores34 colaboradores

•31 com formação superior31 com formação superior

•idade média : 33 anosidade média : 33 anos

6

As nossas competências ...

• Ambientes de Desenvolvimento– Oracle (Developper 2000)– Web

• Tecnologias– Call-Center – Computer Telephony Integration (CTI)– IVR´s– Reconhecimento e síntese de voz

• Sistemas – Billing e Customer Care Systems (BCCS’s) – Operation Support Systems (OSS’s)

7

Índice de conteúdos

• Introdução• O problema• A solução• Conclusão

8

Os desejos do...• … Cliente:– ter tudo o que se lembrar

até ao momento de entrada ao serviço

– gastar pouco (desenvolvimento e manutenção)

• … “Chefe”:– ter tudo o que o cliente se

lembrar até ao momento de entrada ao serviço

– ter as melhores pessoas, sempre motivadas e na equipa

– receber (desenvolvimento e manutenção)

• … Programador:– programar– ter tudo bem percebido

antes de começar a trabalhar

– fazer coisas engraçadas, sempre com a tecnologia ou o produto mais recente

– re-fazer as coisas, optimizando-as

• … Software:– estar correcto e ter

qualidade– ser fácil de usar e manter

9

Evolução do valor do Software

Lançamentodo novo SI

Tempo

Valor do SI

Limiar deactualização do SI

Lançamentode 1 nova

versão

Lançamentode 1 nova

versão

10

Portanto...

• A Engenharia de Software não passa de uma Gestão de Desejos!

11

Índice de conteúdos

• Introdução• O problema• A solução• Conclusão

12

Qualidade de Recursos Humanos

• Há pessoas 10 vezes mais produtivas que outras!

• Diferentes perfis, ambições, etc.– perfil de testes é “destrutivo”– há quem nunca queira deixar de ser

programador, por muita experiência que tenha acumulado!

• Ter em atenção o Princípio de Peter: a evolução na carreira só se dá até se atingir o patamar máximo de incompetência

• Motivar, motivar, motivar!

13

Tarefas de Desenvolvimento de

Software

Tabela 1: Tarefas de desenvolvimento de software.

1. Definição de requisitos 2. Prototipagem 3. Definição da arquitectura

4. Planeamento do projecto 5. Concepção preliminar 6. Concepção detalhada

7. Revisão de concepção 8. Programação 9. Análise de reutilização

10. Aquisição de pacotes 11. Inspecções de código 12. Verificação e validaçãoindependente

13. Gestão de configurações 14. Integração formal 15. Documentação

16. Testes de unidades 17. Testes de funcionalidades 18. Testes de integração

19. Testes de sistema 20. Testes de campo 21. Testes de aceitação

22. Testes independentes 23. Garantia de qualidade 24. Instalação e formação

25. Gestão de projecto

Só os projectos mais exigentes têm todas estas tarefas:Militaresque envolvem risco de vidas

Só a Programação é que garantidamente se faz!

14

Não há UMA metodologia...

• Forma como se encadeiam as diversas tarefas ao longo do tempo

• Pode variar com:– cliente– produto– projecto– tecnologia– equipa desenvolvimento

• Deve ter em conta:– Dinâmica dos requisitos– Entregas frequentes do software

15

Sobreposição de tarefas

0

2 0

4 0

6 0

8 0

1 0 0

1 2 0

1 4 0

1 6 0

1 8 0

1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0

S e m a n a

Tota

l de

Hor

as p

or fa

se

G e s tã o d e p ro je c to G e s tã o d e c o n f ig u ra ç õ e s G a ra n t ia d a q u a lid a d e D e fin iç ã o d e re q u is ito s

A n á lis e e C o n c e p ç ã o D o c u m e n ta ç ã o Im p le m e n ta ç ã o T e s te s

A c e ita ç ã o D is p o n ib iliz a ç ã o à p ro d u ç ã o

D e fin iç ã o R e q u is i to s A n á l is e e C o n c e p ç ã o Im p le m . e te s te s A c e ita ç ã o e p a s s a g e m à p ro d u ç ã o

F ig u r a 1 : E x e m p lo d e e s f o r ç o ( to ta l d e h o r a s tr a b a lh a d a s) p o r c a d a u m a d a s f a s e s d ed e s e n v o lv im e n to d e u m p r o je c to d e so f tw a r e .

16

Tarefas iterativas

Análise

Definiçãode requisitos

Concepção

17

Arquitectura

• Forma como os diversos “componentes” do sistema se organizam e comunicam

• “spaghetti” vs. “ravioli”• Deve ser:

– simples: 7±2– fácil de entender por todos os envolvidos– robusta– flexível

• Inexistência implica difícil evolução e altos custos de manutenção do software

18

Estimativas• Dimensão, esforço, calendário• Quase adivinhação: não usar datas

rigorosas• Depende das métricas:

– linhas de código: desenho de ecrãs? Tabelas de bases de dados?

– Functional points: difícil interpretaçãoCusto projecto

(esforço edim ensão)

Calendárioprojecto

Conceitoinicial doproduto

Conceitoaprovado

do produto

Especificaçãode requisitos

Especificaçãoda concepção

do produto

Especificaçãodetalhada daconcepção

Produtocom pleto

4x

2x

0,25x

0,5x

1,0x

1,6x

0,6x

1,0x

1,25x

0,8x

19

Gestão de riscos

• Diferentes probabilidades• Diferentes impactos• Gestão activa: perseguir o risco

Descrição do risco r Probabilidade(r) Importância(r)

(semanas)

Impacto(r)

(semanas)

Calendarização demasiado optimista 50% 5 2,5

Adição de um requisito que permitaactualizações completamente automáticas apartir do mainframe

5% 20 1,0

Características (ainda indefinidas) adicionaissolicitadas pelo marketing

35% 8 2,8

Interface instável com o subsistema deformatação de gráficos

25% 4 1,0

Concepção desajustada – trabalho extra derevisão

15% 15 2,25

20

Garantia da qualidade

• Testes– Especificação e execução– Detecção e correcção de defeitos, custos:

• 200 vezes + mais caro corrigir um defeito nos testes de aceitação do que na especificação!

– Muitos tipos: unitários, integração, sistema, aceitação, campo

– não são muito eficazes por si só:• mais usados: unitários, só 50% defeitos detectados• mais eficazes: campo (com dados reais), só 65%

defeitos detectados mas em geral caros

• Inspecções, leitura acompanhada

21

UML

• Porquê?– É uma norma: é cada vez mais conhecida

universalmente– é orientado a objectos: facilita a análise,

reutilização– é “configurável”: estereótipos, ...

• …mas é muito complicado?– Não! Deve usar-se “QB”– 90% utilizadores usa apenas

• Diagramas de Casos de Uso• Diagramas de Classes

22

Padrões de desenho• Descrevem “soluções simples e elegantes para

problemas específicos da concepção de software orientado a objectos” [“Design Patterns: Elements of Reusable Object-Oriented Software”, Gamma, Helm, Johnson, Vlissides. Addison Wesley,1994]

• Estas soluções evoluíram no tempo, reflectindo necessidades de reutilização e aumento de flexibilidade

• Outros tipos de padrões: anti-padrões, padrões de análise, padrões de organização, ...

23

Índice de conteúdos

• Introdução• O problema• A solução• Conclusão

24

Conclusão

• É muito complicado gerir os desejos de todos os intervenientes num processo de desenvolvimento de software

• Há cada vez mais ferramentas auxiliares...– “mentais”, independentes de um produto ou

vendedor– baseadas em normas (UML, …)– tecnologias evoluíram muito (internet, Java, …)

• …mas ainda estamos longe do “karma” da ES: fazer software com “engenho”, e não só com “arte”!