Download - Engenharia De Software e O Software Livre

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


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


Engenharia de Software

O que? Como?

Por que?


Engenharia de Software X Futebol

A profissão:

Técnico Engenheiro de Software



Os colaboradores:

Time Equipe



A organização:

Tática (Formação) Modelo (Metodologia)



O resultado:

Títulos = Satisfação do torcedor

Software de qualidade = Satisfação do cliente


Onde o software livre se encaixa nessa analogia?

• O futebol de final de semana: sem técnico, sem organização formal, sem torcedor.


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


Modelo Cascata

Representação gráfica do modelo cascata (PRESSMAN, 1995, p 33).


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


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.);


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


Modelo Espiral

Representação gráfica do modelo espiral (TONSIG, 2003, p63)


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


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


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


Scrum e XP• Scrum é um método ágil para

gerenciamento de projetos;

• XP é um método ágil para gerenciamento de processos;


Scrum

Representação Gráfica do ScrumFonte: http://dojofloripa.wordpress.com/2007/02/07/scrum-em-2-

minutos/


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


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.


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.


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


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.


PMBOK

Representação Gráfica das Áreas de ConhecimentoFonte: http://www.mhavila.com.br/topicos/gestao/pmbok.html


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.


Escolha do ModeloIndicadores

Fonte: Engenharia de Software Magazine, edição especial de 2007


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;


Foto de Eric S. Raymond

http://upload.wikimedia.org/wikipedia/commons

Livro “The Cathedral and the Bazaar”

http://www.timferro.com/wordpress/archives/


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


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


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;


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


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;


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


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;


As Comunidades de SL


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.


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


• 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


Organização Hierárquica


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


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


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


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


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


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


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;


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;


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;


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;


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;


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


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;


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;


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;


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;


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;


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;


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

• [email protected]

• www.twitter.com/jr_dr

Fabio Aiub Sperotto

• [email protected]

• www.twitter.com/fabio_gk

Download - Engenharia De Software e O Software Livre

Top Related