1 Gestão de Desejos Engenharia de Software numa empresa certificada de Telecomunicações José Bonnet FCUP, 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 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

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 Só os projectos mais exigentes têm todas estas tarefas: Militares que 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

16 Tarefas iterativas Análise Definição de 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ção

19 Gestão de riscos Diferentes probabilidades Diferentes impactos Gestão activa: perseguir o risco

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