Carregar apresentação
A apresentação está carregando. Por favor, espere
PublicouLuan Couto Alterado mais de 9 anos atrás
1
1 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
2
2 Índice de conteúdos Introdução O problema A solução Conclusão
3
3 Onde estamos PT Inovação Brasil
4
4 Como nos organizamos (1/2)
5
5 Como nos organizamos (2/2)
6
6 A nossa qualidade... 32 colaboradores 29 com formação superior idade média : 33 anos
7
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
8 Índice de conteúdos Introdução O problema A solução Conclusão
9
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
10 Evolução do valor do Software
11
11 Portanto... A Engenharia de Software não passa de uma Gestão de Desejos!
12
12 Índice de conteúdos Introdução O problema A solução Conclusão
13
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
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
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
16 Sobreposição de tarefas
17
17 Tarefas iterativas Análise Definição de requisitos Concepção
18
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
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
20 Gestão de riscos Diferentes probabilidades Diferentes impactos Gestão activa: perseguir o risco
21
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
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
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
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
25 Wiki! (2/2) http://www.tikiwiki.org
26
26 Índice de conteúdos Introdução O problema A solução Conclusão
27
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
28 Obrigado! ?
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.