1

Gestão de DesejosEngenharia de Software numa empresa

certificada de Telecomunicações

José BonnetFCUP, 2005.Nov.30

ISO 17025 - LABORATÓRIOS ACREDITADOSCETLAB - Laboratório de Redes Privadas e Terminais

CETLCE - Laboratório de Calibração e Ensaio

2

Índice de conteúdos

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

3

Onde estamos

PT Inovação Brasil

4

Como nos organizamos (1/2)

5

Como nos organizamos (2/2)

6

A nossa qualidade ...

•32 colaboradores

•29 com formação superior

•idade média : 33 anos

7

As nossas competências ...

• Ambientes de Desenvolvimento– Web: Java, Java Server Pages, Javascript, XML,

XSLT– Oracle: PL/SQL

• 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)

8

Índice de conteúdos

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

9

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

10

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

11

Portanto...

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

12

Índice de conteúdos

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

13

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!

14

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:– Militares– Que envolvem riscos de vida (Medicina, Espaço, etc.)

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

15

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

16

Sobreposição de tarefas

0

20

40

60

80

100

120

140

160

180

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Semana

Total de Horas por fase

Gestão de projecto Gestão de configurações Garantia da qualidade Definição de requisitos

Análise e Concepção Documentação Implementação Testes

Aceitação Disponibilização à produção

Definição Requisitos Análise e Concepção Implem. e testes Aceitação e passagem à produção

Figura 1: Exemplo de esforço (total de horas trabalhadas) por cada uma das fases dedesenvolvimento de um projecto de software.

17

Tarefas iterativas

Análise

Definiçãode requisitos

Concepção

18

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

19

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 edimensão)

Calendárioprojecto

Conceitoinicial doproduto

Conceitoaprovado

do produto

Especificaçãode requisitos

Especificaçãoda concepção

do produto

Especificaçãodetalhada daconcepção

Produtocompleto

4x

2x

0,25x

0,5x

1,0x

1,6x

0,6x

1,0x

1,25x

0,8x

20

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

21

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

22

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

23

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, ...

24

Wiki! (1/2)

• “a mais simples base de dados que alguma vez poderia funcionar” – Ward Cunningham

• Ferramenta de colaboração e gestão de conteúdos baseada na web

• Sintaxe simples:– hiperligações automáticas entre páginas– Toda a gente pode ser um autor

• http://www.wiki.org

25

Wiki! (2/2)http://www.tikiwiki.org

26

Índice de conteúdos

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

27

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”!

28

Obrigado!

?