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