R RASTREÁVEL

R.1 O requisito possui um identificador único? R.2 A origem do requisito registrado é clara?

R.3 Existe um mecanismo que permite realizar a rastreabilidade do requisito definido na Sprint?

R.4 A rastreabilidade deste requisito com os demais registrados na

R.5 Existe rastreabilidade com todos os requisitos definidos na presente Sprint com as demais Sprint?

Este checklist destina-se aos interessados que empregam a metodologia ágil Scrum. Seu objetivo é avaliar a qualidade dos requisitos registrados em cada Sprint do projeto. O formulário desenvolvido para realizar a validação do mesmo encontra-se em https://docs.google.com/spreadsheet/viewform?formkey=dHJzWEJQeEJsZ1ZJU2hoNlZ4b TA1eGc6MQ8.

A validação semântica do checklist elaborado foi realizada na Fábrica de Software de uma instituição de ensino superior privada e outra pública, ambas localizadas em Anápolis-GO. A mesma validação, também, foi realizada pela comunidade acadêmica e por alguns colaboradores de empresas do setor de Tecnologia da Informação (TI) localizados em Goiânia-GO. Foram sugeridas algumas melhorias no checklist, as quais estão descritas abaixo:

 Acrescentar itens a verificar no checklist relacionados aos tópicos abaixo: o Analisar se o requisito registrado está dentro do escopo da Sprint;

o Analisar se o requisito registrado já foi alocado em outra Sprint ou se o mesmo é duplicado / conflitante com outro;

o Analisar se a “causa raiz” do requisito foi identificada na Sprint.

 Propor um processo para tratar dos requisitos levando em consideração a rastreabilidade e prevenção de mudanças.

O checklist foi utilizado em uma Sprint, com duração de uma semana, em um projeto real em desenvolvimento na Fábrica de Software de uma instituição de ensino superior privada, localizada em Anápolis-GO.

Na Sprint, sete requisitos foram registrados. Para cada um deles, uma verificação foi realizada tomando como base os itens a verificar presente no checklist. Dos vinte e cinco itens a verificar, somente um de cada característica foi escolhido e os respectivos resultados estão ilustrados nos gráficos a seguir. O número do ID (identificador) é o mesmo definido na Tabela 3.

Tabela 4 - Interpretação dos resultados

ID Gráfico Interpretação

C.1 De acordo com a verificação,

57% dos requisitos foram implementados parcialmente na Sprint, enquanto que 43% foram completamente implementados.

Percebe-se que o time não teve um desempenho 100% esperado. Novas adaptações devem ser analisadas para melhorar o desempenho da equipe.

NA.1 71% dos requisitos registrados

na Sprint são suscetíveis a apenas uma interpretação. Somente 14% deles atende parcialmente esse item e os demais 14% são ambíguos.

CO.3 Nessa verificação foi

detectado que 43% dos requisitos alocados na Sprint, contêm toda e somente a informação necessária para produzir o software, enquanto que 29% dos requisitos atende parcialmente essa verificação.

CT.1 43% dos requisitos registrados

na Sprint não está em conflito com qualquer outro requisito definido tanto na mesma quanto em outra Sprint.

Porém, uma taxa de 29% possui algum tipo de conflito e os outros 29% não atende essa verificação.

CI.3 Essa verificação demonstrou que a prioridade de 71% dos requisitos é classificada juntamente com o cliente (ou o Product Owner). 14% dos requisitos não se define a prioridade juntamente com o cliente, enquanto que 14% não define nenhum tipo de prioridade.

V.1 A avaliação desse item

permite constatar que 57% dos requisitos é satisfeito pela implementação ao término da

Sprint de forma parcial. Um

valor de 43% atende completamente essa satisfação. Um fator positivo é que 0% não é satisfeito ou não atende.

M.1 O resultado desse item

demonstra que um mecanismo que objetiva facilitar a modificação de requisitos registrados na Sprint é utilizado em 43% deles. 29% não adota esse mecanismo e os demais 29% utiliza apenas parcialmente esse mecanismo.

R.1 71% dos requisitos registrados

na Sprint possuem um

identificador único, enquanto que 29% não utilizam nenhum tipo de identificador.

Após a utilização do checklist na Sprint desse projeto real, a análise dos resultados obtidos foi realizada, assim como uma reunião de lição aprendida. Nesta reunião todas as sugestões e melhorias identificadas com a aplicação do checklist foram registradas e os métodos para melhorar para a próxima Sprint no projeto foram identificados.

É importante ressaltar que a adoção do Scrum é de suma importância para identificar e entender as reais necessidades do cliente (Product Owner) e fazê-lo entender (ou ele mesmo chegar nesse objetivo) quais são suas necessidades. E, então, em cada

Sprint, estabelecer um planejamento, executá-lo e entregar uma versão funcionando do

produto ao Product Owner.

Segundo a ISO, “as necessidades explicitadas pelo usuário nem sempre refletem suas reais necessidades porque: (1) frequentemente, o usuário não está consciente de suas necessidades reais; (2) as necessidades podem mudar após terem sido explicitadas; (3) usuários diferentes podem ter ambientes operacionais diferentes e (4) pode ser impossível consultar todos os tipos de usuários, particularmente para produtos de software de prateleira. Então, requisitos de qualidade não podem ser completamente definidos antes do início do projeto. Além disto, é necessário entender as necessidades reais do usuário tão detalhadamente quanto possível e representá-las nos requisitos. A finalidade não é, necessariamente, atingir a qualidade perfeita, mas a qualidade necessária e suficiente para cada contexto de uso especificado quando o produto for entregue e utilizado pelos usuários” [ABNT 2003].

Essa afirmação vem de encontro com a política de desenvolvimento do Scrum, pois ele é iterativo e incremental e, por isso, uma vez identificada qualquer modificação ou adaptação com relação às necessidades do cliente, a mesma pode ser planejada, preparada e desenvolvida em uma nova Sprint.

Sendo assim, desenvolver um checklist utilizando as práticas de uma norma que há anos foi elaborada e, além de ser muito bem conceituada no cenário nacional e internacional, permite avaliar um diferencial no conteúdo e na qualidade de bons requisitos definidos para alcançar a qualidade do software desenvolvido.

6. Conclusão

Os resultados obtidos através da validação semântica revelaram a importância em adotar um

Dessa forma, a elaboração dessa proposta de checklist pode facilitar na identificação de possíveis falhas presentes nos requisitos registrados em cada Sprint de um projeto de desenvolvimento de software e contribuir para alcançar altos índices de qualidade do produto produzido. No entanto, sabe-se que, embora sejam importantes, as perguntas presentes no checklist são apenas parte do conjunto de fatores que influenciam na qualidade dos requisitos definidos. Dedicação, interação e auto-organização, tanto do Time quanto do

Product Owner, são fatores primordiais para a garantia da qualidade do produto final em

relação às expectativas do Product Owner.

O Scrum, por ser uma metodologia que não descreve o que fazer em cada situação que pode surgir no decorrer do desenvolvimento do projeto, propõe uma abordagem onde o produto é desenvolvido e entregue parcialmente (dividido em Sprints). Dessa forma, verificar a qualidade dos requisitos definidos em cada Sprint é uma forma de garantir a entrega de um produto final que satisfaça as necessidades do Product Owner. Sugere-se a aplicação do checklist proposto na execução de um projeto real, do início ao fim, para verificar possíveis melhorias e avaliar a eficácia da sua utilização.

Referências

Agile Manifesto (2001). Manifesto for Agile Software Development. Agile Alliance, 2001. Disponível em http://www.agilemanifesto.org/. Acessado em 03.Jan.2012.

Associação Brasileira de Normas Técnicas (2003). NBR ISO/IEC 9126-1: Engenharia de Software – Qualidade de Produto. Parte 1: Modelo de Qualidade.

Beck, K (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. CMMI (2006). Capability Maturity Model Integration (CMMI) for Development. Version

1.2. Disponível em: http://www.sei.cmu.edu/. Acesso em 24.Mar.2012.

Cockburn, A (2004). Crystal clear: a human-powered methodology for small teams. Boston: Adisson-Wesley.

Cohn, M. (2004). Advantages of User Stories for Requirements. Informit Network. Disponível em http://www.mountaingoatsoftware.com/articles/27-advantages-of-user- stories-for-requirements. Acesso em 24.Mar.2012.

Guia do Scrum (2009), Oficial Website. Disponível em: http://www.scrum.org>. Acessado em 15 de Fevereiro de 2012.

Highsmith, J (2002). Agile Software Development Ecosystems. Addison -Wesley, Boston, MA.

IEEE Std 830 (1998) – IEEE Recommended Practice for Software Requirements Specifications. ISBN 0-7381-0332-2.

Kaindl, H., Svetinovic, D (2010). On confusion between requirements and their representations. Requirements Engineering. Volume 15, Number 3, 307-311.

Marçal, A. S. C. (2009). SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI. Dissertação de mestrado, Universidade de Fortaleza.

MPS.BR (2009)a. Guia de Implementação – Parte 4: Fundamentação para Implementação do Nível D do MR-MPS. Disponível em: http://www.softex.br.

MPS.BR (2009)b. Guia Geral do Modelo de Processo de Software (MPS) Brasileiro. Disponível em: http://www.softex.br.

MPS.BR (2009)c. Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do Modelo de Referência-Modelo de Processo de Software (MR-MPS). Disponível em: http://www.softex.br. Acesso em 24.Mar.2012.

Nanda C. S (2007). Using an ethnographic process to conduct requirements analysis for agile systems development. College of Business and Economics, West Virginia

University. Disponível em

http://www.springerlink.com/content/y68254178n327u27/fulltext.html. Acessado em 03.Jan.2012.

PMI (2008). PMBOK Guide: Um guia do conjunto de conhecimentos do gerenciamento de projetos. Project Management Institute (PMI). Pennsylvania: Project Management Institute, 4. ed.

RUP (2012)a. Conceitos: Qualidade do Processo. Rational Unified Process (RUP). Disponível em: http://wthreex.com/rup/process/workflow/environm/co_sqlty.htm. Acessado em 15.Jan.2012.

RUP (2012)b. Conceitos: Gerenciamento de Requisitos. Disponível em http://www.wthreex.com/rup/process/workflow/requirem/co_rm.htm. Acesso em 22.Mar.2012.

Salgado, A (2010). Aplicação de um Processo Ágil para Implantação de Processos de Software baseado em Scrum na Chemtech.

Sayão, M., Leite, J. C. S. P. (2003). Rastreabilidade de Requisitos. Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Schwaber, K (2004). Agile Project Management With Scrum, Microsoft Press, Redmond, Washington, USA.

Soares, M. S. (2004). Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Universidade Presidente Antônio Carlos. Gigante.

Sommerville, I (2011). Engenharia de Software. trad. André Maurício de Andrade Ribeiro. 9a ed. São Paulo: Pearson Addison Wesley.

SWEBOK (2004). Guide to the Software Engineering Body of Knowledge. Version. A project of the IEEE Computer Society Professional Practices Committee. Disponível em: http://www.swebok.org.

PROPOSTA DE ESTRUTURAÇÃO DO ESCRITÓRIO DE PROCESSOS NA