Engenharia de Software Livre e o Software Livre

Engenharia de
Software Livre e
o Software Livre
Valcir Júnior Dalla Rosa
Fabio 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

Futebol
Os colaboradores:
Time Equipe

Futebol
A organização:
Tática (Formação) Modelo (Metodologia)

Futebol
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 Scrum
Fonte: 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 12207
Fonte: 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 Conhecimento
Fonte: 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 Modelo
Indicadores
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/common
s
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
• vjdr@unochapeco.edu.br
• www.twitter.com/jr_dr
Fabio Aiub Sperotto
• fabioaiub@unochapeco.edu.br
• www.twitter.com/fabio_gk

Engenharia de Software Livre e o Software Livre

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (8)

Similaire à Engenharia de Software Livre e o Software Livre

Similaire à Engenharia de Software Livre e o Software Livre (20)

Engenharia de Software Livre e o Software Livre