Post on 21-Jun-2015
description
Engenharia de Software Livre e o Software Livre
Valcir Júnior Dalla RosaFabio Aiub Sperotto
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
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).
Free Template from www.brainybetty.com 4
Engenharia de Software
O que? Como?
Por que?
Free Template from www.brainybetty.com 5
Engenharia de Software X Futebol
A profissão:
Técnico Engenheiro de Software
Free Template from www.brainybetty.com 6
Engenharia de Software X Futebol
Os colaboradores:
Time Equipe
Free Template from www.brainybetty.com 7
Engenharia de Software X Futebol
A organização:
Tática (Formação) Modelo (Metodologia)
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
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.
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).
Free Template from www.brainybetty.com 11
Modelo Cascata
Representação gráfica do modelo cascata (PRESSMAN, 1995, p 33).
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;
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.);
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;
Free Template from www.brainybetty.com 15
Modelo Espiral
Representação gráfica do modelo espiral (TONSIG, 2003, p63)
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.
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).
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).
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;
Free Template from www.brainybetty.com 20
Scrum
Representação Gráfica do ScrumFonte: http://dojofloripa.wordpress.com/2007/02/07/scrum-em-2-
minutos/
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;
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.
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.
Free Template from www.brainybetty.com 24
Padrões
Representação Gráfica dos Processos da ISO/IEC 12207Fonte: http://www.plugmasters.com.br/sys/materias/539/1/ISO
%7B47%7DIEC-12207-Processos-Fundamentais
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.
Free Template from www.brainybetty.com 26
PMBOK
Representação Gráfica das Áreas de ConhecimentoFonte: http://www.mhavila.com.br/topicos/gestao/pmbok.html
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.
Free Template from www.brainybetty.com 28
Escolha do ModeloIndicadores
Fonte: Engenharia de Software Magazine, edição especial de 2007
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;
Free Template from www.brainybetty.com 30
Foto de Eric S. Raymond
http://upload.wikimedia.org/wikipedia/commons
Livro “The Cathedral and the Bazaar”
http://www.timferro.com/wordpress/archives/
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;
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.
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;
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.
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;
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.
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;
Free Template from www.brainybetty.com 38
As Comunidades de SL
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.
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;
Proposta de Modelo
Colaborativo de Desenvolvimento
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
Free Template from www.brainybetty.com 43
Organização Hierárquica
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;
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;
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,
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,
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;
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.
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;
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;
Free Template from www.brainybetty.com 52
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;
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;
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;
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);
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;
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;
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;
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;
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;
Free Template from www.brainybetty.com 62
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;
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;
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