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