1 Gestão de Desejos Engenharia de Software numa empresa certificada de Telecomunicações José Bonnet FCUP, 2005.Nov.30 ISO LABORATÓRIOS ACREDITADOS CETLAB - 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 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

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

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

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

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

25 Wiki! (2/2)

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