Extração de dados sobre
requisitos/riscos de evolução
em um ambiente colaborativo de
desenvolvimento de software
Aluno: Alexandre L. Silva
Agenda
• Introdução
• Estudo sobre ambientes colaborativos
• Avaliação de um projeto com método ágil
• Riscos antes, durante e depois do projeto
• Hipótese observada
• Hipótese de solução técnica
• Estado da arte
• Objetivo
• Conclusão
• Bibliografia
05/11/2015
Alexandre L. Silva © LES/PUC - Rio
2
Introdução
• Gerenciamento do ciclo de vida de aplicativos
– Gestão entre pessoas, processos e informações, através do uso de
ferramentas
– Benefícios:
• Aumento de produtividade
• Aumento de qualidade
• Melhora a interatividade
• Acelera o desenvolvimento
• Reduz o tempo de manutenção
• Maximiza os investimentos em
competência, processos e tecnologias
05/11/2015
Alexandre L. Silva © LES/PUC - Rio
3
Introdução
• Gerenciamento de configuração
– Identificar mudanças convenientes e rastrear os impactos das
mudanças aceitas
– Antecipar riscos e prever as ações para minimizar os impactos
– Atividades principais:
• Planejamento de gerenciamento de configurações
• Gerenciamento de mudanças
• Gerenciamento de versões
• Construção de sistemas
05/11/2015
Alexandre L. Silva © LES/PUC - Rio
4
Introdução
• Ciclo de vida colaborativo
• Riscos existentes:
– Envolvimento coordenado
entre os membros da equipe
– Restrição política: Divergência de
interesses
– Pilares:
– Restrição tecnológica:
Planejamento de arquitetura
• Colaboração/Cooperação
• Comunicação
• Distribuição
• Automação
05/11/2015
– Restrição financeira: Visibilidade do
investimento
• Melhoria contínua
– Restrição de recursos humanos:
Equipes heterogêneas
• Rastreabilidade
– Restrição em processos: Burocracia
Alexandre L. Silva © LES/PUC - Rio
5
Estudo sobre ambientes colaborativos
• Gerência em ambientes colaborativos:
– As pessoas colaboram. As equipes se autoorganizam.
– Os processos facilitam o fluxo de eventos, além de indicar qual demanda foi
entregue e quando.
– O planejamento define o escopo das demandas e quem as realizará.
– As informações são compartilhadas em repositórios.
– As ferramentas são especificas para as tarefas do usuário.
• Importância da colaboração:
– Empenho na colaboração: Políticas de colaboração, organização e princípios
– Acessibilidade:
• Visibilidade sobre o ciclo de vida do artefato
• Melhoramento contínuo
– Responsabilidade de todos:
• Os participantes devem se adaptar ao meio
• Os participantes devem promover a integração dos demais
– Inspeção: Deve-se ter conhecimento do trabalho dos outros
– Melhoria: Os participantes devem incentivar a qualidade no trabalho
Estudo sobre ambientes colaborativos
• Importância das ferramentas no apoio à gerência:
– Diminuem a distância entre os envolvidos
• Equipes distribuídas geograficamente ou em locais diferentes dentro da
empresa
– Visibilidade:
• Os itens de trabalho e o código fonte estão acessíveis
• Identificação da saúde do projeto
• Análise de mudanças e impactos
– Transparência:
• Auditoria
• Facilita a tomada de decisões
Estudo sobre ambientes colaborativos
• Importância das informações/métricas:
– Ser facilmente coletada
– Pertencer a um conjunto pequeno de métricas e diagnósticos
– Fornecer feedback frequente e regular
– Responder uma pergunta específica para uma pessoa real
– Seguir tendências e não números
– Incentivar a comunicação
– Revelar, ao invés de esconder, seu contexto e suas variáveis
Gráfico de burndown
Figura 7: Gráfico de burndown
Avaliação de um projeto com método ágil
• Cliente:
– Empresa de comércio eletrônico
– A empresa detém o domínio do conhecimento de negócio
• Objetivo:
– Gerar uma versão web de um sistema vital
• Expectativa:
– Gerar um sistema flexível e de fácil manutenção, com uma
arquitetura corporativa, através de componentes reutilizáveis
• Início do projeto em maio/2010
Avaliação de um projeto com método ágil
• Histórico resumido
– O desenvolvimento começou com requisitos definidos com poucos
detalhes
– Durante esse trabalho, foi preciso treinar a equipe que estava
distante
– Em alguns momentos, houve conflito de versões no controlador de
versões, com consequente perda de código pronto
– Depois de alguns meses de trabalho, a arquitetura foi modificada
– Com a nova arquitetura, foram adicionadas novas tecnologias ao
projeto
– O projeto passou a ser dividido entre outras equipes de
desenvolvimento
– As mudanças eram constantes no banco de dados
Avaliação de um projeto com método ágil
• Análise de riscos durante o projeto:
– Falta de visão a médio e longo prazo
– Falta de detalhamento de requisitos
• Definição dos requisitos através da descrição existente e mockup de telas
– Demora na definição da arquitetura do sistema
• Ao estabilizar a arquitetura, já havia muito código pronto, gerando
retrabalho inútil
– A equipe distante era muito novata
• O tempo de aprendizagem sobrecarregou alguns integrantes da equipe
local
– Estimativas com métricas variáveis
• Não havia uma métrica coerente para a avaliação de esforço
– Expectativa grande X Pouco tempo e equipe reduzida
• Entrega imediata X Eng. De Software
Riscos antes, durante e depois do projeto
• Antes:
– Faça a análise de viabilidade
– Avalie a compatibilidade com métodos ágeis
– Identifique os interessados
– Motive as equipes
• Durante
– Proponha a análise de requisitos de maneira simples
– Antecipe a proposta de arquitetura
– Faça primeiro os itens que agregam mais valor ao negócio
– Mantenha pontos contínuos de revisão
– Revise os objetivos das próximas iterações
– Indique o que será alterado, construído e testado
– Avalie o crescimento do desempenho das equipes
Riscos antes, durante e depois do projeto
• Depois:
– Avaliar a organização do projeto
– Provavelmente vai ocorrer evolução ou manutenção do sistema
– A natureza dos projetos de manutenção está próxima do ambiente de
desenvolvimento iterativo
Hipótese observada
• Manutenção ou melhoria são mudanças
• Caminho natural das demandas: as demandas geram mudanças
no escopo dos requisitos
Hipótese de solução técnica
• Realizar a gestão de requisitos/impactos através de matriz de
rastreabilidade
REQ1
REQ2
REQ3
REQ1
CDU1
Classe 1
CDU2
Classe 2
CDU3
Classe 3
REQ2
REQ3
• Geração de matrizes nos projetos:
– Não existe geração
– Geração manual
– Geração semiautomática
Dificuldade de análise de riscos
Estado da arte
• Rastreabilidade:
– Mesmo em projetos pequenos ou de tamanho moderado, o
estabelecimento de elos de rastreabilidade, entre artefatos-chave e
modelos, continua sendo uma tarefa desafiadora e cara. (Neumuller;
Grunbacher, 2006)
– Embora a rastreabilidade seja legalmente requerida na maioria das
aplicações de segurança crítica, e seja reconhecida como um componente
de muitas iniciativas de melhoria em processos de software, as
organizações ainda lutam para implementá-la de modo que ofereça um
bom custo-benefício. (Cleland-Huang, 2006)
05/11/2015
Alexandre L. Silva © LES/PUC - Rio
17
Estado da arte
• Mineração de repositórios de software:
– O campo da mineração de repositórios de software está amadurecendo
graças à facilidade de acesso e à quantidade de informações disponíveis
nos repositórios de software. (Hassan, 2008)
• Riscos
– Toda mudança é considerada no contexto de risco pois essa mudança
pode introduzir defeitos no software. (Cordy, 2008)
• MSR 2012 - The 9th Working Conference on Mining Software
Repositories (junto com a ICSE)
05/11/2015
Alexandre L. Silva © LES/PUC - Rio
18
Objetivo
• Aprimorar a gerência de riscos e mudanças através de
rastreabilidade automatizada e transparente
• Realizar a mineração de repositórios de software das bases de
svn no laboratório, com o objetivo de gerar matrizes de
rastreabilidade, para apoiar a gestão de mudanças em requisitos
de software
Ferramentas de controle de versão
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Microsoft Visual SourceSafe
SourceGear Vault
Perforce
Borland StarTeam
BitKeeper
Monotone
OpenCM
GNU Arch
Serena PVCS Version Manager
MKS Source
CVS (Concurrent Version System)
and TortoiseCVS
Subversion and TortoiseSVN
Microsoft Team Foundation System
(TFS)
IBM Rational ClearCase
Comportamento no tempo
Visão geral da mineração de repositórios de software
REQ1
REQ2
REQ3
CDU1
CDU2
CDU3
REQ1
Classe 1
Classe 2
Classe 3
REQ2
REQ3
Conclusão
• Antecipar a proposta de arquitetura:
– Revisar alguns requisitos não funcionais
• Identificar o perfil dos interessados:
– Aliar interesse com expectativas
– Promover a transparência aos interessados
• Promover a colaboração:
– A responsabilidade é diluída
• Toda iteração é um mini projeto:
– No início de cada iteração, a gerência de configuração avalia o
impacto dos requisitos
• Observar constantemente as ferramentas:
– Alguns sintomas são percebidos facilmente
Bibliografia
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
AMBLER, S. W. The Agile System Development Life Cycle (SDLC)
AMBLER, S. W. Effective Practices for Modeling and Documentation
AMBLER, S. W. The Disciplined Agile Delivery (DAD) Lifecycle
AMBLER, S. W. A Manager's Introduction to The Rational Unified Process (RUP)
AMBLER, S. W. Justifying a Software Development Project
BACKES, J. Rastreabilidade Semi-Automática Através de Mapeamento de Entidades
BRADLEY, A., MURPHY, G., Supporting Software History Exploration
CLELAND-HUANG, J. Just Enough Requirements Traceability
COHN, M., KEITH, C. How to Fail with Agile
Cordy, J. Comprehending Reality - Practical Barriers to Industrial Adoption of Software Maintenance
Automation
COLLINS-SUSSMAN, B., FITZPATRICK, B., PILATO, C. Version Control with Subversion
DOSHI, H. Sprint Burndown says a lot about your scrum team...
GOTTESDIENER, E. RAD Realities: Beyond the Hype to How RAD Really Works
Hassan, A.E. The road ahead for Mining Software Repositories.
IBM Corporation. Melhorando o desempenho dos projetos com processos comprovados e adaptáveis
MIRANDA, P. Auditoria de Sistemas
NEUMULLER, C.; GRUNBACHER, P. Automating Software Traceability in Very Small Companies: a case study
and lessons learned.
PACHECO, D. Seja inteligente e não use Agile
SOMMERVILLE, Ian. Software Engineering
SATO, D. Métricas de Acompanhamento para Metodologias Ágeis
Tortoisesvn Project Home
WIKIPEDIA.ORG. IBM Rational Unified Process
WIKIPEDIA.ORG. Dynamic Systems Development Method
05/11/2015
Alexandre L. Silva © LES/PUC - Rio
23