Engenharia De Software e O Software Livre

Engenharia de Software Livre e o Software Livre Valcir Júnior Dalla Rosa Fabio Aiub Sperotto

Roteiro • Engenharia de Software (conceitos); • Modelos Relacionados (clássicos, ágeis, normas e gestão); •dfds Comunidade de Software Livre; • Proposta de um Modelo Colaborativo; • Conclusões. Free Template from www.brainybetty.com 2

Engenharia de Software • “O estabelecimento de sólidos princípios de engenharia para que se possa obter economicamente um software confiável e que funcione dfds eficientemente em máquinas reais." (BAUER apud PRESSMAN,1995, p. 31). Free Template from www.brainybetty.com 3

Engenharia de Software O que? Como? Por que? Free Template from www.brainybetty.com 4

Engenharia de Software X Futebol A profissão: Técnico Engenheiro de Software Free Template from www.brainybetty.com 5

Engenharia de Software X Futebol Os colaboradores: Time Equipe Free Template from www.brainybetty.com 6

Engenharia de Software X Futebol A organização: Tática (Formação) Modelo (Metodologia) Free Template from www.brainybetty.com 7

Engenharia de Software X Futebol O resultado: Títulos = Software de qualidade = Satisfação do torcedor Satisfação do cliente Free Template from www.brainybetty.com 8

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 9

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 10

Modelo Cascata Representação gráfica do modelo cascata (PRESSMAN, 1995, p 33). Free Template from www.brainybetty.com 11

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

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 13

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

Modelo Espiral Representação gráfica do modelo espiral (TONSIG, 2003, p63) Free Template from www.brainybetty.com 15

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

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 17

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 18

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 19

Scrum Representação Gráfica do Scrum Fonte: http://dojofloripa.wordpress.com/2007/02/07/scrum-em-2- minutos/ Free Template from www.brainybetty.com 20

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

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 22

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 23

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 Free Template from www.brainybetty.com 24

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 25

PMBOK Representação Gráfica das Áreas de Conhecimento Fonte: http://www.mhavila.com.br/topicos/gestao/pmbok.html Free Template from www.brainybetty.com 26

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 27

Escolha do Modelo Indicadores Fonte: Engenharia de Software Magazine, edição especial de 2007 Free Template from www.brainybetty.com 28

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 29

Livro “The Cathedral and the Bazaar” http://www.timferro.com/wordpress/archives/ Foto de Eric S. Raymond http://upload.wikimedia.org/wikipedia/common s Free Template from www.brainybetty.com 30

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

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

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 33

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

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 35

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

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 37

As Comunidades de SL Free Template from www.brainybetty.com 38

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 39

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; Free Template from www.brainybetty.com 40

Proposta de Modelo Colaborativo de Desenvolvimento

Objetivos • 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; Free Template from www.brainybetty.com 42

Organização Hierárquica Free Template from www.brainybetty.com 43

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

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

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

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

Á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; 48 Free Template from www.brainybetty.com

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

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 50

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 51

Free Template from www.brainybetty.com 52

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 53

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 54

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 55

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 56

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 57

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 58

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 59

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 60

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 61

Free Template from www.brainybetty.com 62

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 63

Conclusões • É importante que colaboradores de outras áreas entendam a filosofia do SL e também o modelo; • Comunidades Universitárias de SL; Free Template from www.brainybetty.com 64

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

Engenharia De Software e O Software Livre

by Fabio Sperotto on Sep 30, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 62

Statistics

Engenharia De Software e O Software Livre — Presentation Transcript

http://www.slideshare.net	27
http://blogmaiconbastos.blogspot.com	18
http://blogmaiconbastos.blogspot.com.br	17