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