Your SlideShare is downloading. ×
Engenharia De Software e O Software Livre
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Engenharia De Software e O Software Livre

2,364
views

Published on

Slides da palestra sobre Engenharia de software aplicado ao software livre, uma proposta de um modelo de colaboração desenvolvida pelo Valcir Júnior Dalla Rosa com contribuição de Fabio Aiub Sperotto. …

Slides da palestra sobre Engenharia de software aplicado ao software livre, uma proposta de um modelo de colaboração desenvolvida pelo Valcir Júnior Dalla Rosa com contribuição de Fabio Aiub Sperotto. No núcleo de pesquisas de software livre na Unochapecó.
Este é um trabalho em andamento e já houve correções sobre os conceitos apresentados, entre em contato (www.bazardoconhecimento.wordpress.com).

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,364
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
97
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Engenharia de Software Livre e o Software Livre Valcir Júnior Dalla Rosa Fabio Aiub Sperotto
  • 2. Free Template from www.brainybetty.com 2 dfds • Engenharia de Software (conceitos); • Modelos Relacionados (clássicos, ágeis, normas e gestão); • Comunidade de Software Livre; • Proposta de um Modelo Colaborativo; • Conclusões. Roteiro
  • 3. Free Template from www.brainybetty.com 3 Engenharia de Software dfds • “O estabelecimento de sólidos princípios de engenharia para que se possa obter economicamente um software confiável e que funcione eficientemente em máquinas reais." (BAUER apud PRESSMAN,1995, p. 31).
  • 4. Free Template from www.brainybetty.com 4 Engenharia de Software O que? Como? Por que?
  • 5. Free Template from www.brainybetty.com 5 Engenharia de Software X Futebol A profissão: Técnico Engenheiro de Software
  • 6. Free Template from www.brainybetty.com 6 Engenharia de Software X Futebol Os colaboradores: Time Equipe
  • 7. Free Template from www.brainybetty.com 7 Engenharia de Software X Futebol A organização: Tática (Formação) Modelo (Metodologia)
  • 8. Free Template from www.brainybetty.com 8 Engenharia de Software X Futebol O resultado: Títulos = Satisfação do torcedor Software de qualidade = Satisfação do cliente
  • 9. Free Template from www.brainybetty.com 9 Onde o software livre se encaixa nessa analogia? • O futebol de final de semana: sem técnico, sem organização formal, sem torcedor.
  • 10. Free Template from www.brainybetty.com 10 Modelos de Processo de Software • É uma proposta teórica de organização das fases envolvidas no processo de produção do software; • Não é uma descrição definitiva, mas sim, uma representação abstrata do gerenciamento e desenvolvimento do software (SOMMERVILLE, 2001).
  • 11. Free Template from www.brainybetty.com 11 Modelo Cascata Representação gráfica do modelo cascata (PRESSMAN, 1995, p 33).
  • 12. Free Template from www.brainybetty.com 12 • Caracteriza-se pela seqüencialidade das atividades de uma forma sistemática, a passagem de uma tarefa para outra tem como requisito a validação e aceitação dos produtos finais da tarefa atual;
  • 13. Free Template from www.brainybetty.com 13 Prototipação • Esse modelo baseia-se na idéia de criação de protótipos, que inicialmente representam apenas a interface; • Em outra etapa, desenvolve-se funcionalidades que serão aprovadas pelo cliente, (módulos, relatórios, etc.);
  • 14. Free Template from www.brainybetty.com 14 • A idéia é que o protótipo evolua até se suprir todas as necessidades do cliente; • Dois tipos de protótipos: – Descartável; – Não descartável;
  • 15. Free Template from www.brainybetty.com 15 Modelo Espiral Representação gráfica do modelo espiral (TONSIG, 2003, p63)
  • 16. Free Template from www.brainybetty.com 16 • A abordagem tradicional considera quatro etapas fundamentais, onde cada etapa é representada por um quadrante do ciclo; • A cada iteração completada, o software evolui para estágios superiores, normalmente aumentando sua complexidade.
  • 17. Free Template from www.brainybetty.com 17 Metodologias Ágeis • “As metodologias ágeis surgiram com a proposta de aumentar o enfoque nas pessoas e não nos processos. Além disso, existe a preocupação em gastar menos tempo com documentação e mais tempo com a resolução do problema”. (SOARES, 2004, p 2).
  • 18. Free Template from www.brainybetty.com 18 Manifesto Ágil • Indivíduos e interações ao invés de processos e ferramentas; • Software executável ao invés de documentação; • Colaboração do cliente ao invés de negociação de contratos; • Respostas rápidas a mudanças ao invés de seguir planos. (BENK, Kent et al, 2001).
  • 19. Free Template from www.brainybetty.com 19 Scrum e XP • Scrum é um método ágil para gerenciamento de projetos; • XP é um método ágil para gerenciamento de processos;
  • 20. Free Template from www.brainybetty.com 20 Scrum Representação Gráfica do Scrum Fonte: http://dojofloripa.wordpress.com/2007/02/07/scrum-em-2- minutos/
  • 21. Free Template from www.brainybetty.com 21 • Divide o desenvolvimento em sprints, responsáveis por funcionalidades (requisitos) específicas; • O produto é projetado, codificado e testado durante o sprint; • No final de cada sprint cada equipe apresenta os resultados do seu trabalho para o grupo, sendo que existem reuniões diárias de 15 minutos;
  • 22. Free Template from www.brainybetty.com 22 Papéis no Scrum • Product Owner: o cliente, dono do produto; • Scrum Master: o técnico, o gerente da equipe, responsável pela qualidade do trabalho. • Team: a equipe de trabalho; • Developers: desenvolvedores.
  • 23. Free Template from www.brainybetty.com 23 Padrões • ISO/IEC 12207: define uma estrutura comum para o clico de vida do software (processos, atividades e tarefas). Conceito de acoplamento.; • ISO/IEC 15504: avaliação de processos de software com foco em melhorias dos processos.
  • 24. Free Template from www.brainybetty.com 24 Padrões Representação Gráfica dos Processos da ISO/IEC 12207 Fonte: http://www.plugmasters.com.br/sys/materias/539/1/ISO %7B47%7DIEC-12207-Processos-Fundamentais
  • 25. Free Template from www.brainybetty.com 25 PMBOK • Formaliza o ciclo de vida do software: iniciação, planejamento, execução, monitoramento e controle, encerramento. • Formaliza 9 áreas de conhecimento: integração, escopo, tempo, custos, qualidade, recursos humanos, comunicação, riscos e aquisição.
  • 26. Free Template from www.brainybetty.com 26 PMBOK Representação Gráfica das Áreas de Conhecimento Fonte: http://www.mhavila.com.br/topicos/gestao/pmbok.html
  • 27. Free Template from www.brainybetty.com 27 Escolha do Modelo • Considerar peculiaridades e a natureza de cada projeto e o resultado a ser alcançado. • Definir prioridades: controle, agilidade, qualidade, etc. • Considerar o tamanho da equipe.
  • 28. Free Template from www.brainybetty.com 28 Escolha do Modelo Indicadores Fonte: Engenharia de Software Magazine, edição especial de 2007
  • 29. Free Template from www.brainybetty.com 29 O Processo de Desenvolvimento de Software Livre • Livro e artigo referência no assunto: “The Cathedral and the Bazaar” de Eric S. Raymond ; • Raymond escreve sobre os métodos de engenharia de software utilizado no processo de produção do sistema operacional Linux, sendo este open source;
  • 30. Free Template from www.brainybetty.com 30 Foto de Eric S. Raymond http://upload.wikimedia.org/wikipedia/common s Livro “The Cathedral and the Bazaar” http://www.timferro.com/wordpress/archives/
  • 31. Free Template from www.brainybetty.com 31 • Segundo Raymond (2001), o processo de produção de software livre é praticado desde 1980; • Muitos dos modelos citados acima, principalmente as metodologias ágeis, ainda não haviam sido desenvolvidos ou não estavam plenamente consolidados como modelos seguros;
  • 32. Free Template from www.brainybetty.com 32 • Raymond baseou-se na observação do processo de produção do Linux para caracterizar dois métodos produção de software: o método Catedral e o método Bazar.
  • 33. Free Template from www.brainybetty.com 33 Método Catedral • O software é produzido por uma pequena equipe; • O código, durante o processo de desenvolvimento, está acessível somente a está equipe; • O código (ou programa compilado) é liberado pra comunidade quando já possui certo grau de confiabilidade;
  • 34. Free Template from www.brainybetty.com 34 • Possibilita a existência de uma hierarquia bem definida; • A fase de teste é geralmente realizada por uma comunidade maior; • Esse método de produção pode ser observador na produção de software proprietário ou de software livre produzidos em empresas.
  • 35. Free Template from www.brainybetty.com 35 Método Bazar • Software é produzido por uma grande comunidade; • os códigos são liberados e testados constantemente; • Os desenvolvedores geralmente encontram-se geograficamente distribuídos comunicando-se pela internet;
  • 36. Free Template from www.brainybetty.com 36 • Não possui uma hierarquia bem definida, sendo a organização extremamente informal, valendo- se do conceito de auto-organização bottom-up; • Este método é encontrado em comunidades de software livre.
  • 37. Free Template from www.brainybetty.com 37 As Comunidades de SL • Geralmente se organizam como “Bazar”; • Na maioria das vezes o trabalho não é remunerado; • Os colaboradores (mantedores e contribuidores) encontram-se geograficamente distribuídos. • MERITOCRACIA;
  • 38. Free Template from www.brainybetty.com 38 As Comunidades de SL
  • 39. Free Template from www.brainybetty.com 39 O Resultado • A esmagadora maioria das comunidades não se desenvolvem, pelo simples fato do software não parecer interessante. • Comunidades maiores possuem certa organização (funções, regras, objetivos), e algumas até incentivo financeiro.
  • 40. Free Template from www.brainybetty.com 40 O Problema • Não existe nenhum modelo formal para o SL; • Os modelos já desenvolvidos são orientados ao cliente; • Não consideram as peculiaridades do SL;
  • 41. Proposta de Modelo Colaborativo de Desenvolvimento
  • 42. Free Template from www.brainybetty.com 42 • Não pretende revolucionar a produção de software livre, mas mostrar-se como uma alternativa. • Considerar peculiaridades: - A inexistência de um cliente; - Colaboradores distribuídos geograficamente; - Colaboradores não possuem comprometimento efetivo (suporte); - Falta de recursos financeiros; Objetivos
  • 43. Free Template from www.brainybetty.com 43 Organização Hierárquica
  • 44. Free Template from www.brainybetty.com 44 Áreas de Conhecimento • Ponto chave desse modelo; • O especialista de cada área executa sua função (“dividir para conquistar”); • Evitar sobrecarga de trabalho sobre o mediador; • Melhorar a qualidade de cada tarefa executada; • Cada área é dividida em setores e os setores em funções;
  • 45. Free Template from www.brainybetty.com 45 Área Técnica • Pilar da comunidade; • Onde o software em si é produzido; • Ex: programação, análise, teste; • Possui o papel do gerente técnico: - Define setores, funções e quem ocupara cada função; - Delegação de tarefas; - Fiscalização do cronograma;
  • 46. Free Template from www.brainybetty.com 46 Área Técnica • Equipes verticais: formadas por colaboradores com a mesma função, sendo responsável por uma fase (processo) da produção. • Equipes horizontais: Possui profissionais de várias funções que são responsáveis pela solução de um requisito. (Scrum) : programadores, testadores, analistas,
  • 47. Free Template from www.brainybetty.com 47 Área de Consultoria • Formada por colaboradores especialistas em uma área de conhecimento necessária para a produção do software; • Ajuda no levantamento, definição e validação dos requisitos; • Cabe ao consultor o poder de abstrair o problema de uma forma genérica e não apenas para resolver o seu problema; programadores, testadores, analistas,
  • 48. Free Template from www.brainybetty.com 48 Área de Tradução • A tradução de software livre é uma prática já consolidada pelas comunidades, porém, geralmente não possui uma área específica; • A área de tradução pode trabalhar junto com área de tradução para a divulgação de forma global; • Aumentar a qualidade e a gama de idiomas;
  • 49. Free Template from www.brainybetty.com 49 Área de Publicidade • Não existe na maioria das comunidades; • Várias comunidades de software livre possuem dificuldades para se promover; • Empresas de publicidade podem utilizar a comunidade para promover seus serviços; • Colaboradores que realmente entendem de promoção podem aumentar a quantidade de usuários e até mesmo colaboradores.
  • 50. Free Template from www.brainybetty.com 50 Conclusões sobre o Organograma • Usuário possui voz ativa (feedback); • Não tem como objetivo burocratizar o processo de produção de software livre; • Organizá-lo incentivando a colaboração de novas áreas de conhecimento com a filosofia de liberdade peculiar ao software livre;
  • 51. Free Template from www.brainybetty.com 51 Processos de Desenvolvimento da Comunidade e do Software • Além do desenvolvimento do software livre é preciso considerar o desenvolvimento da comunidade; • Para a criação da comunidade existe a necessidade de um idealizador;
  • 52. Free Template from www.brainybetty.com 52
  • 53. Free Template from www.brainybetty.com 53 Estudo de Viabilidade • Análise de todos os fatores relevantes ao desenvolvimento do software e criação da comunidade; • Pode ser feito pelo idealizador junto com um possível consultor da comunidade; • Caso seja viável deve-se imediatamente identificar o mediador;
  • 54. Free Template from www.brainybetty.com 54 Definição das Áreas, Setores, Funções e Colaboradores • Deve ser feita por um mediador, sendo que, na área técnica os responsável pela definição dos setores, funções e colaboradores deve ser feita pelo “gerente técnico”. • Quando destas atividades concluídas a organização hierarquia encontra-se estruturada;
  • 55. Free Template from www.brainybetty.com 55 Levantamento dos Requisitos • Deve ser feito por algum colaborador (engenheiro de requisito) da área técnica juntamente com o consultor de cada área; • Dependendo do software há a necessidade de mais áreas; • Mais consultores da mesma área pode ser interessante;
  • 56. Free Template from www.brainybetty.com 56 Elicitação dos Requisitos • Executada por colaboradores da área técnica pelo levantamento dos requisitos (documento de requisitos); • Artefatos de análise são gerados: diagramas, fluxogramas, roteiros,etc. • É importante que os requisitos sejam bem definidos e documentados (levantamento e análise);
  • 57. Free Template from www.brainybetty.com 57 Codificação • O artefatos gerados pelo levantamento e análise dos requisitos são utilizados para a codificação da solução; • Aspectos técnicos como linguagem de programação, são resolvidos pela equipe de programação, considerando o problema; • Conforme são codificados os requisitos podem ser testados;
  • 58. Free Template from www.brainybetty.com 58 Teste Técnico • Pode ser feito por uma equipe de teste ou por alguém pertencente a equipe técnica que não seja o colaborador que o codificou; • Ex de aspecto técnico: “erro quando a tecla x é clicada”, “campo com tipo de dado errado”, “mensagens erradas”, “problema de ergonomia na interface”, etc. • Se o código não é válido ele volta pra codificação para que as devidas mudanças sejam feita;
  • 59. Free Template from www.brainybetty.com 59 Teste do Consultor(es) • Refere-se a saída dos programas; • Validação do requisito; • Cada consultor atesta o código para os aspectos da sua área; • Quando um requisitos não é validado e sofre refatoração antes de ser codificado novamente;
  • 60. Free Template from www.brainybetty.com 60 Publicação • Após a validação das duas fases de teste ocorre a publicação; • Publicação de todos os artefatos (documentação) gerados e não somente do código; • Facilita a compreensão do software (estudo), possível customização e manutenção;
  • 61. Free Template from www.brainybetty.com 61 Processo de Manutenção • Qualquer colaborador pode propor uma alteração ou aperfeiçoamento; • O mediador faz um estudo de impacto viabilidade sobre esta modificação juntamente com os consultores; • Caso a proposta seja viável, um novo requisito pode ser criado ou um requisito existente pode sofrer alteração;
  • 62. Free Template from www.brainybetty.com 62
  • 63. Free Template from www.brainybetty.com 63 Conclusões • O modelo apresentado pode ser melhor gerenciado com uma ferramenta on-line; • Quem está acostumado ao processo tradicional de desenvolvimento de software livre pode apresentar resistência; • A utilização de conceitos e modelos da engenharia de software vem para trazer confiança e qualidade a software livre;
  • 64. Free Template from www.brainybetty.com 64 Conclusões • É importante que colaboradores de outras áreas entendam a filosofia do SL e também o modelo; • Comunidades Universitárias de SL;
  • 65. Contato Valcir Júnior Dalla Rosa • vjdr@unochapeco.edu.br • www.twitter.com/jr_dr Fabio Aiub Sperotto • fabioaiub@unochapeco.edu.br • www.twitter.com/fabio_gk