Gerência de Requisitos: MPS.BR, BABOK e Agile possuem algo em comum? Uma experiência no Governo com software Open Source

Transcrição

1 Gerência de Requisitos: MPS.BR, BABOK e Agile possuem algo em comum? Uma experiência no Governo com software Open Source

2 O INEP Autarquia federal vinculada ao Ministério da Educação (MEC), criada em 1937 com 360 servidores Missão: promover estudos, pesquisas e avaliações sobre o Sistema Educacional Brasileiro com o objetivo de subsidiar a formulação e implementação de políticas públicas para a área educacional a partir de parâmetros de qualidade e equidade, bem como produzir informações claras e confiáveis aos gestores, pesquisadores, educadores e público em geral. Realiza levantamentos estatísticos e avaliativos em todos os níveis e modalidades de ensino.

3 A DTDIE A Diretoria de Tecnologia e Disseminação de Informações Educacionais, é responsável por: planejar, propor e desenvolver mecanismos, instrumentos e produtos de disseminação e documentação de informações educacionais do Inep, oferecendo suporte à divulgação de resultados e produtos dos sistemas de avaliação e de indicadores e estatísticas educacionais. administrar os recursos de Tecnologia da Informação e coordenar e executar o desenvolvimento de software na organização

4 Software no INEP 2011: Metodologia de Gestão e Desenvolvimento de Sistemas (MGDS) Tem como norte o desenvolvimento ágil de software O alinhamento com práticas tradicionais (Open UP, PMBOK e UML) é necessário por requisitos legais previstos na IN 04 Presume uma elaboração progressiva

5 Requisitos Necessidades que motivaram o Gerenciamento de Requisitos: o uso dos artefatos previstos na MGDS gerou também alguns novos desafios: Carga extra de trabalho para os papéis envolvidos no tocante à revisão e homologação de cada artefato; Essas atividades acabavam por prorrogar o tempo de entrega das demandas; Problemas de comunicação diversos, envolvendo a documentação entregue, seu versionamento e o formato de redação; Ausência de rastreabilidade de requisitos.

6 INEPRH O sistema busca automatizar as rotinas administrativas referentes às atividades dos servidores do INEP. Foi escolhido para realização de um piloto com ferramenta Open Source que permitisse a implementação da rastreabilidade de requisitos e reduzisse o impacto dos problemas identificados

7 O software Redmine O software Redmine é uma aplicação flexível para o gerenciamento de projetos via web. Utiliza o framework Ruby on Rails e é open source, distribuído nos termos da licença GNU General Public License v2 (GPL). Entre as características que influenciaram na decisão de uso estão: Suporte a múltiplos projetos: Controle de acesso flexível baseado em papéis Sistema de rastreamento de questões (issue tracking) flexível Uso de feeds e notificações por Integração com SCM (SVN, em particular)

8 O uso do BABOK O BABOK Business Analysis Body Of Knowledge, mantido pelo IIBA International Institute for Business Analysis serviu de base para definir o que o Inep usaria em termos de rastreabilidade de requisitos. Nesse caso, o piloto serviu também como ensaio sobre como as atividades de Análise de Negócios poderiam ser incorporadas ao ciclo de desenvolvimento de software.

9 Proposta Inicial Nível 1 Necessidade de Negócio: Serve para o Mapeamento das razões (em alto nível) que levaram ao desenvolvimento da solução.

10 Proposta Inicial Nível 2 Requisitos de Negócio e Requisitos de Stakeholders: São rastreados a partir um de uma ou mais necessidades de negócio e podem conter relacionamentos entre si.

11 Proposta Inicial Nível 3 Requisitos Funcionais, Nãofuncionais e de Transição: Identificam os requisitos da solução, e são rastreados a partir de elementos do nível 2. No caso do Inep, sempre são soluções de software. Podem conter relacionamentos entre si.

12 Proposta Inicial Nível 4 Histórias de Usuário e Casos de Uso: São rastreados a partir de elementos do nível 3. Na MGDS é permitido o uso de ambos em um projeto. Podem conter relacionamentos entre si.

13 Proposta Inicial Nível 5 Cenários de Teste e Casos de Teste e Regras de Negócio: São rastreados a partir de elementos do nível 4 e podem conter relacionamentos entre si.

14 Uso da Ferramenta

15 Uso da Ferramenta

16 Uso da Ferramenta

17 Uso da Ferramenta

18 Uso da Ferramenta

19 Uso da Ferramenta

20 GRE MPS.Br Aderência ao modelo MPS.Br Em análise livre direcionada ao Nível G, observou-se compatibilidade entre os resultados obtidos com o GRE. GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos; (Atende) GRE 2. Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido; (Atende) GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; (Atende) GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; (Atende) GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. (Atende)

21 GRE MPS.Br Aderência ao modelo MPS.Br Em análise livre direcionada ao Nível G, observou-se compatibilidade entre os resultados obtidos com o GRE. GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos; (Atende) GRE 2. Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido; (Atende) GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; (Atende) GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; (Atende) GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto. (Atende)