factories X OSS development...
• conjunções e intersecções
• métodos e ferramentas
• processo
• modelos
• licenças
• vendas
Free Software Engineering: A Field to Explore
Gonzáles-Barahona and Robles
UPGRADE Vol. IV No. 4 August 2003http://www.upgrade-cepis.org/issues/2003/4/upgrade-vIV-4.html
Free Software Projects
• Nascem como iniciativa isolada e particular
• Usuários são co-desenvolvedores
• Divulgação “boca-a-boca”
• Teste massificado pelos usuários
• Gerência de versões é complexa e “bem-definida”
Open Source Projects
• (Sun apr 16 00:10:21 BRT 2006) 133,421 projects!• Communications (13469)• Database (5388)• Desktop Environment (2822)• Education (3252)• Formats and Protocols (1292)• Games/Entertainment (12694)• Internet (21951)• Multimedia (11518)• Office/Business (6136)• Other/Nonlisted Topic (2065) • Printing (417) • Religion and Philosophy (274)• Scientific/Engineering (9942)• Security (2494)• Sociology (355)• Software Development (18587)• System (17790)• Text Editors (2436)
Open Source Projects• (Sun apr 22 20:18:32 BRT 2007) 189,827 projects!• Communications (18979)• Database (7090)• Desktop Environment (3843)• Education (5076)• Formats and Protocols (3014)• Games/Entertainment (17723)• Internet (29002)• Multimedia (15900)• Office/Business (9960)• Other/Nonlisted Topic (2620) • Printing (526) • Religion and Philosophy (341)• Scientific/Engineering (15436)• Security (3350)• Sociology (442)• Software Development (29007)• System (23545)• Text Editors (3275)
http://sourceforge.net/
Causas de Descontinuidade de Projetos SW Livre
• Falta de interesse, tempo ou motivação– mudança de liderança nos projetos impactam
sua continuidade
• Code Forking– cada usuário tem acesso ao código e pode
alterá-lo e redistribuí-lo sem o conhecimento do líder do projeto
http://www.math.uconn.edu/~bass/scdp.pdf
Free Software EngineeringResume
• “A Field to Explore”• “is still in its infancy” (2003!)• “How to create free software? Issues:
– Classification of free software projects– Creation of a methodology– Methods + classification + models ++
Simulation (intelligent agents) = Free SW Engineering”
A Framework for creating hybrid-open source software
communities
Srinarayan Sharma
et. al.
Info Systems
(2002), 12.
The OSS model
• Three dimensions:– structure, process and culture
structure culture
process
Eletronic communication
Multicultural community
Values: reciprocity, gift giving, reputation, ideology
Core assumptions
Division of labour
Co-ordination mechanisms
Distribution od decision-making
Organizational boundaries
Informal structure
Political structure
Legitimate basis of authority
Framework for creating Hybrid-
OSS communities
Principles:
• Community building
• Community governance– Shared governance– Membership management– Incentives and rewards
• Community infrastructure
Discussion
... open source communities versus Software Factories?
• personal time and autonomy... freelancers
... project-oriented
• ... there are several avenues for future research– ... to refine the proposed framework and validate it
empirically
linhas-mestrasIN953 – Engenharia de Software
• Process Implementation – Software Factories (Gibeon, Ana Paula, Thayssa)
• F/L/OSS (Alan)
• OSS Business Model (Alan, Ana Paula, Aisa)
• Scientific Relevant Projects (Convidados)
• Business & Humanitas (TODOS!)
fábricas de software
princípiosconceitosilusões
fábrica de sw na prática
• Operação profissional• Processo de desenvolvimento transparente• Retorno rápido ao cliente• Alta produtividade
• Ferramentas e processos padronizados
• Alta qualidade• Dados históricos, previsibilidade e análise de risco
• Reusabilidade de código[1968 G&E, R. W. Berner]
[2003 IEEE Computer Vol.36 Num.3, B. Boehm][2005 IEEE Software Vol. 22 Num 2, PostModern SW Design]
Cathedral and Bazaar
e Desenvolvimento de Software
segundo Eric Raymond, 1997• Alguns projetos são como Cathedrals– altamente centralizados em
poucas pessoas que decidem projeto e implementação
– para fazer parte deve-se aceitar as definições
http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
Outros são como Bazaars (sw livre)
• Sem planejamento detalhado mas orientados!• Linux Kernel (www.linux.org): “hierarchical”
– Linus Torvalds, “The Benevolent Dictator”
• APACHE Foundation (www.apache.org): “meritocracy”– Para fazer parte você deve ter colaborado continuamente
em projetos da fundação
• GCC (gcc.gnu.org): “steering Commitee”
Conceitos
The factory is an organization inhabited by people engaged in a common effort, work is organized one way or the other, standardization is used for coordination and formalization, and systematization is important, but there will be several options for the design of a particular software factory
[Aaen, Botcher, Mathiassen, Software Factories, 1997]http://www.cin.ufpe.br/~in953/papers/Software_Factories_17.pdf
fábricas de software: 4 estratégias...
• Japonesa (1981,1987)– SWB – Software Work Bench
• Européia (1991,1992)– ISDE – Integrated Software Development
Environment
• Norte-Americana – experiência produção (1989,1993)
• Norte-Americana – níveis de maturidade (1990,1993)
Estratégia Japonesa• Aumento de produtividade e qualidade de
desenvolvimento e manutenção• Estratégia baseada em infra-estrutura: física,
organizacional e ferramental• Uso de métricas• Metodologia padronizada para todos os projetos• Reuso em todas as fases• Foco em tecnologia
Estratégia Européia• Ambientes integrados de desenvolvimento orientados a
cliente (IDEs)• Estratégia orientada a ferramentas: padronização de
componentes, adaptação de processo• Sem métricas formais• Metodologia adaptada por projeto• Sem reuso formal• Foco em Tecnologia
(Organizacional... ISO-9000)
Estratégia Norte Americana 1• Baseada em Componentes• Maior eficácia de processos, menos re-trabalho e mais reuso• Estratégia de melhoria contínua baseada na experiencia adquirida• Sem métricas rigorosas• Metodologia adaptada por projeto • Reuso• Sem foco em tecnologia, foco em pessoas!
(...Ágeis...XP – Extreme Programming, SCRUM)
Estratégia Norte Americana 2• Processo eficaz, previsível, confiável e auto-melhorável• Estratégia de melhoria em etapas, níveis de maturidade• Uso de métricas• Metodologia adaptada por projeto• Pouco reuso• Pouco foco em tecnologia
(Processos... RUP, CMM...)
...considerações...
The four approaches are important contributions towards this goal. At the same time the approaches individually may lead to unfortunate illusions. Learning from the relative strengths and weaknesses between the approaches may help us avoid becoming victims of these illusions
[Aaen, Botcher, Mathiassen, Software Factories, 1997]http://www.cin.ufpe.br/~in953/papers/Software_Factories_17.pdf
...e ilusões...
fábrica de software ≠ produção em massa
padronização, formalização, especialização, controle ≠ produção de software com
qualidade
o que fazer?
building a software factory...[Making the software factory work... 1990-1999]
http://www.cin.ufpe.br/~in953/papers/MakingTheSoftwareFactoryWorkLessonsFromADecadeOfFactory.pdf
1. to define a detailed software development process2. staff members were given extensive training in the
new process3. process specification separated from process execution4. data collection and analysis
1. interviews2. software process assesments3. process attributes for each project4. configuration management system5. project tracking data
o PROCESSO é complexo!
(c) MERX LLC
Elaborado: OJS - Revisão: CAB, JPML, GMR - Aprovado: CAB - Versão 0
Fábrica de Software da Ampla Consultoria em Informação
Prospecção
Execução
PLT
Execução
Proposta
Proposta
Encerramento
Garantia
Execução
PPPP
PC
PCPP PP
PROT
PPF
PT
DR
PC
PC PROTDRPTPPF
MER
DR
PPF
PT
PC
PPF
PP
PT
MER
UC
MER
UC
DR
DR
DR
MER
UC
DR
PROT
DR
DRPROT
DR
UC
AR
MER
PROT
N
S
N
S
S
N
OK?
RevisarRequisitos,
interfaces, casosde uso e MER
Gc
Criar PropostaComercial
Líder Equipe 2
Validar requisitos
Criar PropostaTécnica e Plano
de Projeto
Validar interfacese requisitos
Técnicos
Cl
Líder Equipe 1
Gc
Gerente de Projetos
Di
Agendar visitaspara apresentaçãoe/ou elicitação de
requisitos
Diretor
Identificardemandas que
possam seratendidas pelas
áreas deconhecimento
Gp
Projetar interfaces
Técnicos
Gc
Cliente
Requisitos/escopoestão claros?
Gp
Prototiparinterfaces
Projetarinterfaces?
1
Técnicos
De
Gerente ComercialGerente de Tecnologia
Gerente de Processos e Qualidade
Início
Gp
Líder Equipe n
Análise de Pontosde Função
Gc Di
Gc Gp
GcCl Gp
Gp
Gp Gc
Gp
N
S
S Revisões?
Projetoaprovado?
C
1
Registrarsuspensão do
projeto
Apresentar PC,PT e DR
Revisar DR, PT,PPF, PC e PROT.
Di GpGc
Gp
N
S Renegociar?
Revisarcronograma
Revisar PropostaComercial
Avaliar riscos
Preparar ambientede
desenvolvimento
Lp
Lp
Reavaliarnecessidades de
treinamento
Lp
Gp
Reavaliar recursoshumanos,software ehardware
LpGp
Lp
Gp GcDi
S
S
N
S
N
S
N
N
S
S N
Fim
PP
OK?
MER MER
DR
Implementar
A
Projetar banco dedados
PT
Apresentarrequisito paradesenvolvedor
PC
DS (o)
BIntegrar?
Corrigir
Preparar Plano deTeste
Lp
B
Solicitação demudanças
PLT
SM
Selecionarrequisito
Cl
Avaliar solicitação
DR
PLT
Problemas naimplementação?
Realizar Teste deUnidade
Comunicar Líderdo Projeto
PC
Revisar requisitos,plano de projeto
De
Realizar casos deuso
De
DI (o) Nãoconformidades?
PP
DS (o)
Agendar reuniãocom cliente
MER
PT
B-1
PC
Aprovarmudanças?
PLT
DR
Lp
PP
A
DI (o)
PP
Revisar requisitose plano de projeto
3
DR
Renegociar
PT
Lp
PT
Pode ser resolvidointernamente?
A-1
B-2
Encerrarsolicitação
DC
B-2
Especificar casosde teste de
unidade
A-2
PC
RIT
Lp
Gp
DC
GpSM
Início
De
Gc
SM
Lp
Gp Gc
Gp Gc
LpCl
Di
GpLp
Lp
De
De
S
N
S
N
PP
B
Nãoconformidades?
PP
PP
3
RIT
Analisar nãoconformidades e
planejarimplementação
Gp
RIT
DeGq
Analisar nãoconformidades e
planejarimplementação
B
Realizar Teste deSistema
Realizar Teste deIntegração
Nãoconformidades?
NS
N
S
S
N
Iniciar período degarantia(90 dias)
Analisar
Gq
PP
Preparar materialde treinamento
PO
PP
B
DR
De
Agendartreinamento
Gp
B
Realizartreinamento
DRProblema
encontrado?
PT
Gp
PC
Instalar econfigurarsoftware
Aceitação totalou parcial?
Procede?
Analisar
DR
De
AR
Teste deaceitação
(com cliente)
De
DeGp
Realizar pesquisade opinião
C
Reunião deencerramento
(equipe)
RM
KB
De
Gp
AR
Di
Gp
Avaliar resultadosdo projeto
Gq
Lp
Registrarencerramento do
projeto
Fim
PO
Gp
Artefato
Artefato fonte
Artefato produzido
Fluxo do processo
Processo
Ponto de decisão
Responsabilidade
Di DiretorCl ClienteGc Gerente ComercialGt Gerente de TecnologiaGp Gerente de ProjetosGq Gerente de Processos e QualidadeLp Líder do ProjetoDe Desenvolvedor
Atores
Artefatos
AR_<Cód. do Projeto>_<aaaammdd> Ata de ReuniãoDR_<Cód. do Projeto>_V<99>.<99> Documento de RequisitosPT_<Cód. do Projeto>_V<99>.<99> Proposta TécnicaPC_<Cód. do Projeto>_V<99>.<99> Proposta ComercialPP_<Cód. do Projeto>_V<99>.<99> Plano de ProjetoMER_<Cód. do Projeto>_V<99>.<99> Modelo de Entidades e RelacionamentosPLT_<Cód. do Projeto>_V<99><99> Plano de TesteRIT_<Cód. do Projeto>_V<99><99> Relatório de Incidentes de TesteMU_<Cód. do Projeto>_V<99>.<99> Manual do UsuárioPO_<Código do Projeto> Pesquisa de OpiniãoPROT_<aaaammdd> Protótipo (Na pasta I)SM_<Cód. do Projeto>_V<99>.<99> Solicitação de MudançasUC_<Cód. do Projeto>_V<99>.<99> Caso de UsoPPF_<Código do Projeto>_V<99>.<99> Pontos por FunçãoDC_<Código do Projeto>_V<99>.<99> Diagrama de ClassesDS_<Código do Projeto>_V<99>.<99> Diagrama de SequênciaDI_<Código do Projeto>_V<99>.<99> Diagrama de InteraçãoRA_<Código do Projeto>_V<99>.<99> Relatório de AceitaçãoRM_<Código do Projeto>_V<99>.<99> Relatório de Melhorias no ProcessoKB Knowledge Base
(o) = Opcional
Gp DeGq
GpCl
GpGq
Gq
Gq Gp De
Gq
PP
RA
Encerramento
MER
DR
PPF
PT
PC
PPF
PP
PT
MER
UC
MER
UC
DR
DRDR
MER
UC
DR
ReviseRequirements,
interfaces, E-Rand Use Cases
Gc
Build CommercialProposal
Build TechnicalProposal and
Project Plan
DiGc
Gp
1
Gp
Function PointAnalysis
Gp Gc
Gp
Contrato
Execução
Entrega
Prospecção
processo é complexo... Ex.: Amplaprocesso é complexo... Ex.: Ampla
Process Implementation
Sarah Sheard
Software Productivity Consortium
Thursday, July 3, 2003
or,We’ve documented all our
processes—what’s left to do?
So what does it take?
1. Manage as a project
2. Obtain management support
3. Establish policy
4. Establish measurement baseline
5. Train employees and managers
6. Tailor processes
7. Maintain process assets
8. Ensure processes are being used
9. Learn Lessons
10. Improve Processes
11. Appraise the organization
Process Implementation Requires Everyone!
• Senior management sets the tone and ensures other managers make PI happen
• SEPG drives the process improvement program to its goals
• Projects review processes, tailor standard processes, use their tailored versions, and recommend improvements
• QA audits independently
Funciona para SW Livre?
• Adaptação de Processos de 1990?• 2007! Distributed Development...
• O que fazer?– Ler– Praticar– Montar experimentos reais e avaliar...
um desenvolvimento sem processo...
SISTEMAS SÃO SISTEMAS SÃO ENTREGUES!!ENTREGUES!! Mas...Mas...
Acúmulo de TrabalhoAcúmulo de Trabalho
Descontinuidade de Descontinuidade de planosplanos
Prazos, custos... Prazos, custos... EstouramEstouram
Time de heróisTime de heróis
Clientes sem Clientes sem atendimentoatendimento
Engenharia de Produção de Software: histórico
• 60´s Fábrica de Software (1958!!!)
• 70´s Kanbam• 70´s Just In Time• 80´s SIGMA• 90´s CMM• 00´s Fábrica de
Software... • PMBOK, ISO, MPS-
BR... Modelos!
alternativas... MPS.BR
• Melhoria do Processo de Software Brasileiro
– Boas Práticas– Experiência de pequenas e médias empresas– Custos reduzidos– Aderência a outros Modelos– Escalabilidade e praticidade
A: Em OtimizaçãoA: Em Otimização (Inovação e Implantação na Organização – IIO) (Análise e Resolução de Causas – ARC) B: Gerenciado QuantitativamenteB: Gerenciado Quantitativamente (Desempenho do Processo Organizacional – DEP) (Gerência Quantitativa do Projeto – GQP) C: DefinidoC: Definido (Gerência de Riscos – GRI) (Análise de Decisão e Resolução – ADR) D: Largamente DefinidoD: Largamente Definido (Desenvolvimento de Requisitos – DRE) (Validação – VAL) (Solução Técnica – STE) (Verificação – VER) (Integração do Produto – ITP) (Instalação do Produto – ISP) (Liberação do Produto – LIP)
E: Parcialmente DefinidoE: Parcialmente Definido (Treinamento – TRE) (Definição do Processo Organizacional – DFP) (Avaliação e Melhoria do Processo Organizacional – AMP) (Adaptação do Processo para Gerência de Projeto – APG) F: GerenciadoF: Gerenciado (Gerência de Configuração – GCO) (Medição – MED) (Garantia da Qualidade – GQA) (Aquisição – AQU)
G: Parcialmente GerenciadoG: Parcialmente Gerenciado (Gerência de Projeto – GPR) (Gerência de Requisitos – GRE)
MPS.BR MR-MPS v1.0 2005MPS.BR MR-MPS v1.0 2005(23) Processos, organizados em
(7) Níveis de Maturidade
Baseados naISO/IEC 12207,ISO/IEC 15504, eCMMI-SE/SW
Nível CMMI correspondente:
5
4
3
2
[Salviano 2005]
What is institutionalization?
No, not that kind!
e as pessoas?...
(c) MERX LLC
MASLOW
Trabalho em Equipe
O trabalho em equipe é um processo baseado em
princípios e valores que estão claramente definidos e entendidos. O verdadeiro trabalho em
equipe é um processo contínuo interativo de um grupo de pessoas aprendendo, crescendo e
trabalhando interdependentemente para alcançar metas e objetivos específicos no suporte a
uma missão comum.
ORGANIZAÇÕES ESTRUTURAIS X
BASEADAS EM HABILIDADES
ORGANIZAÇÕESTRADICIONAIS:
Realizam tarefas funcionais; Pessoa em segundo plano; O controle é a meta;
Visão a curto prazo; Informação, formação, e incentivos,
não são importantes; Repetem os ciclos de reestruturação
e regressão.
ORGANIZAÇÕES BASEADAS EM HABILIDADES:
Realizam bem, as tarefas com funções cruzadas;
As pessoas são valorizadas; A meta é valorizar o que constitui
valor para os clientes; Visão a longo prazo; Informação, formação e incentivos,
são importantes; Criam um padrão de melhoria
permanente.
o que “sabemos” aqui?• TODO o pressman ou sommerville (Software
Engineering)
• ou seja:– requisitos, especificações, refinamento, validação e
verificação, métodos, técnicas, linguagens e ferramentas, componentes, reutilização, manutenção, modelagem de processos, qualidade, reengenharia,, verificação, validação e teste... além de programação JAVA++!...
– {faltaria o quê?}
Top Related