extração de dados sobre requisitos/riscos de evolução em um ambiente colaborativo de...
TRANSCRIPT
Extração de dados sobre requisitos/riscos de evolução
em um ambiente colaborativo de desenvolvimento de software
Aluno: Alexandre L. Silva
11/04/23 2Alexandre L. Silva © LES/PUC - Rio
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
11/04/23 3Alexandre L. Silva © LES/PUC - Rio
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
11/04/23 4Alexandre L. Silva © LES/PUC - Rio
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
11/04/23 5Alexandre L. Silva © LES/PUC - Rio
Introdução
• Ciclo de vida colaborativo
– Envolvimento coordenado entre os membros da equipe
– Pilares:
• Colaboração/Cooperação
• Comunicação
• Distribuição
• Automação
• Melhoria contínua
• Rastreabilidade
• Riscos existentes:
– Restrição política: Divergência de interesses
– Restrição tecnológica: Planejamento de arquitetura
– Restrição financeira: Visibilidade do investimento
– Restrição de recursos humanos: Equipes heterogêneas
– Restrição em processos: Burocracia
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
• Geração de matrizes nos projetos:
– Não existe geração
– Geração manual
– Geração semiautomática
REQ1 REQ2 REQ3
CDU1
CDU2
CDU3
REQ1 REQ2 REQ3
Classe 1
Classe 2
Classe 3
Dificuldade de análise de riscos
11/04/23 17Alexandre L. Silva © LES/PUC - Rio
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)
11/04/23 18Alexandre L. Silva © LES/PUC - Rio
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)
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 REQ2 REQ3
Classe 1
Classe 2
Classe 3
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
11/04/23 23Alexandre L. Silva © LES/PUC - Rio
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