Gestão de Desejos
Engenharia de Software numa empresa
certificada de Telecomunicações
José Bonnet
FCUP, 2005.Nov.30
ISO 17025 - LABORATÓRIOS ACREDITADOS
CETLAB - Laboratório de Redes Privadas e Terminais
CETLCE - Laboratório de Calibração e Ensaio
1
Índice de conteúdos
•
•
•
•
Introdução
O problema
A solução
Conclusão
2
Onde estamos
PT Inovação Brasil
3
Como nos organizamos
(1/2)
4
Como nos organizamos
(2/2)
5
A nossa qualidade ...
•32 colaboradores
•29 com formação superior
•idade média : 33 anos
6
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)
7
Índice de conteúdos
•
•
•
•
Introdução
O problema
A solução
Conclusão
8
• … 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)
Os desejos do...
• … 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
Valor do SI
Limiar de
actualização do SI
Lançamento
de 1 nova
versão
Lançamento
do novo SI
Tempo
Lançamento
de 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ção
independente
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!
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
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
180
Definição Requisitos
Total de Horas por fase
160
Aceitação e passagem à produção
Implem. e testes
Análise e Concepção
140
120
100
80
60
40
20
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Semana
Figura 1: Exemplo de esforço (total de horas trabalhadas) por cada uma das fases de
desenvolvimento de um projecto de software.
16
Tarefas iterativas
Definição
de requisitos
Concepção
Análise
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ção
Custo projecto
(esforço e
dimensão)
4x
Calendário
projecto
1,6x
2x
1,25x
1,0x
1,0x
0,5x
0,8x
Produto
completo
0,25x
Conceito
inicial do
produto
0,6x
Conceito Especificação Especificação Especificação
aprovado de requisitos da concepção detalhada da
do produto
do produto
concepção
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)
Impacto(r)
(semanas)
(semanas)
Calendarização demasiado optimista
50%
5
2,5
Adição de um requisito que permita
actualizações completamente automáticas a
partir do mainframe
5%
20
1,0
Características (ainda indefinidas) adicionais
solicitadas pelo marketing
35%
8
2,8
Interface instável com o subsistema de
formatação de gráficos
25%
4
1,0
Concepção desajustada – trabalho extra de
revisã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
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
24
Wiki! (2/2)
http://www.tikiwiki.org
25
Índice de conteúdos
•
•
•
•
Introdução
O problema
A solução
Conclusão
26
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”!
27
Obrigado!
?
28