Aluno: Alexandre L. Silva

Apresentação em tema: "Aluno: Alexandre L. Silva"— Transcrição da apresentação:

1 Aluno: Alexandre L. Silva
Extração de dados sobre requisitos/riscos de evolução em um ambiente colaborativo de desenvolvimento de software Aluno: Alexandre L. Silva

2 Alexandre 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 25/03/2017 Alexandre L. Silva © LES/PUC - Rio

3 Alexandre 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 25/03/2017 Alexandre L. Silva © LES/PUC - Rio 3 3

4 Alexandre 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 25/03/2017 Alexandre L. Silva © LES/PUC - Rio 4 4

5 Alexandre 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 25/03/2017 Alexandre L. Silva © LES/PUC - Rio 5 5

6 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

7 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

8 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

9 Figura 7: Gráfico de burndown

10 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

11 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

12 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

13 Riscos antes, durante e depois do projeto
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

14 Riscos antes, durante e depois do projeto
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

15 Hipótese observada Manutenção ou melhoria são mudanças
Caminho natural das demandas: as demandas geram mudanças no escopo dos requisitos

16 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

17 Alexandre 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) 25/03/2017 Alexandre L. Silva © LES/PUC - Rio 17 17

18 Alexandre 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 The 9th Working Conference on Mining Software Repositories (junto com a ICSE) 25/03/2017 Alexandre L. Silva © LES/PUC - Rio 18 18

19 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

20 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

21 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

22 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

23 Alexandre 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 25/03/2017 Alexandre L. Silva © LES/PUC - Rio