* Com co-autoria de Allan Bessa e Gleison Santos

A etapa de levantamento de requisitos está comumente presente nos projetos de construção de software, uma vez que as necessidades dos usuários são obtidas a partir de algum tipo de coleta dessas informações através de entrevistas, questionários, protótipos, etnografia, estudos de casos de uso, dinâmicas entre a equipe do projeto (JAD – Joint Application Design) e etc. (Nuseibeh e Easterbrook, 2000).

Apesar da disponibilidade dessas boas técnicas, alguns analistas não as utilizam, comprometendo assim o atendimento às expectativas dos usuários, tornando os sistemas complexos de serem utilizados (Carrizo et al., 2008) e fora do contexto das cinco características principais da usabilidade: facilidade de manuseio e capacidade de aprendizado rápido; dificuldade de esquecimento; ausência de erros operacionais; satisfação do usuário e; eficiência na execução das tarefas a que se propõe (Leal Ferreira e Nunes, 2008).

Um estudo de caso foi realizado envolvendo dois projetos, sendo um deles através da técnica de prototipação (Projeto P) e outro não (Projeto X). Os projetos foram avaliados em cima de um contexto real e da forma quantitativa a partir da comparação de funcionalidades similares e com o uso de uma abordagem para mensuração do processo de software, o GQM (Goal Question Metric). A execução desses dois projetos foi realizada em uma consultoria multinacional do setor de Tecnologia da Informação (TI) e pela mesma equipe em períodos diferentes num total de 11 profissionais.

Na fase de elicitação de requisitos foi criado um wireframe ou “esqueleto” principal no projeto P, a fim de delimitar as áreas distintas, organizar o conteúdo, padronizar as informações, manter uma identidade visual e uma consistência nas interfaces a serem construídas. Tanto o front end como o back end tiveram as funcionalidades revistas constantemente entre a equipe de requisitos, o designer e o cliente no intuito de tornar cada vez mais compreensível o conteúdo apresentado para os usuários. Já no projeto X optou por adotar uma gama de templates pré-definidos como modelos para desenvolvimento, sem passar pela fase de organização das informações em protótipos conforme ocorrido com o projeto P.

Definição dos objetivos, questões e métricas

O método GQM é um paradigma orientado a metas a fim de mensurar produtos e os processos de software. Dessa forma, estabelece metas/objetivos daquilo que se propõe a medir e suas respectivas questões e métricas (Basili, 1992), conforme apresentado na Tabela 1.

Tabela 1. Objetivo do estudo de caso de acordo com o GQM

As questões, apresentadas na Tabela 2 foram baseadas nas quatro fases envolvidas no processo de construção de software adotadas pela consultoria em TI e compreendidas em: 1 – elicitação de requisitos, fase de levantamento das necessidades junto aos usuários; 2 – design, elaboração dos protótipos; 3 – construção, fase de desenvolvimento das necessidades obtidas nas fases de elicitação e design; 4 – testes, fase de execução de testes integrados e homologação junto aos usuários.

As métricas foram estipuladas a fim de obter a produtividade em relação ao percentual entre as horas executadas com as horas planejadas, como também, as horas de retrabalho em relação às horas executadas para cada questão/fase.

Entende-se neste estudo como retrabalho as horas aquém estipuladas e executadas por meio de retorno de avaliação de testes unitários e testes integrais de sistemas, bem como de erros ocasionados por problemas de má interpretação dos documentos de requisitos e de funcionalidades ruins quanto à usabilidade das interfaces.

Tabela 2. Questões e Métricas de acordo com o objetivo do estudo de caso

A seguir são apresentadas as hipóteses do estudo.

Hipótese Nula (H₀): A produtividade com o uso da técnica de elicitação de requisitos por prototipação (ou seja, no projeto P) são menores do que naqueles projetos sem a utilização dessa técnica (ou seja, no projeto X).

P ? X: ( ((EE_P ? EE_X) ou (ER_P ? ER_X)) e

((DE_P ? EE_X) ou (DR_P ? DR_X)) e

((CE_P ? CE_X) ou (CR_P ? CR_X)) e

((TE_P ? TE_X) ou (TR_P ? TR_X)) )

Hipótese Alternativa (H₁): A produtividade com o uso da técnica de elicitação de requisitos por prototipação (ou seja, no projeto P) são maiores do que naqueles projetos sem a utilização dessa técnica (ou seja, no projeto X).

P > X: ( ((EE_P < EE_X) ou (ER_P < ER_X)) e

((DE_P < DE_X) ou (DR_P < DR_X)) e

((CE_P < CE_X) ou (CR_P < CR_X)) e

((TE_P < TE_X) ou (TR_P < TR_X)) )

Coletas de Dados

Os dados foram coletados a partir de um sistema de gestão de projetos da organização. As horas das atividades executadas foram processadas em uma planilha eletrônica e um sumário é apresentado nas Tabelas 3 e 4.

Tabela 3. Coleta de dados do estudo de caso no projeto P

Tabela 4. Coleta de dados do estudo de caso no projeto X

Interpretação dos Resultados e Testes das Hipóteses

A partir do total das horas coletadas, ilustrado na tabela 5, os resultados das métricas foram gerados conforme a tabela 6.

Tabela 5. Total de horas das funcionalidades

Tabela 6. Resultados das métricas a partir das horas coletadas

As métricas M11, M21, M31 e M41 se basearam nas horas executadas com as horas planejadas. Na fase de elicitação de requisitos, por exemplo, o projeto X obteve 32 horas a mais que às 70 horas planejadas, ou seja, 45,71% (M11), onde: (102h – 70h / 70) * 100, enquanto o projeto P obteve 7,14%. Constata-se também esta variação positiva nas demais fases dos projetos.

Nas métricas M12, M22, M31 e M42 referentes às horas de retrabalho, obtiveram-se horas a mais no projeto X em relação ao P em todas as fases. Por exemplo, na fase de design, o projeto X consumiu 28 horas a mais que às 15 horas executadas, sendo 186,67%, ou seja: (28h / 15h) * 100.

Por meio dos resultados dessas métricas, os testes foram gerados a partir da substituição das hipóteses nula e alternativa, conforme Tabelas 7 e 8.

Tabela 7. Hipótese Nula H0 (P ? X)

Tabela 8. Hipótese Alternativa H1 (P &gt X)

Dessa forma, a hipótese nula (H0) foi negada e, assim, a hipótese alternativa (H1) foi considerada verdadeira.

O analista de testes no projeto P foi o que menos teve retrabalho em relação aos demais papéis envolvidos na execução do projeto. O designer foi quem registrou mais retrabalho, realizou testes de interface e usabilidade retornando as funcionalidades para desenvolvimento e refinamento antes de publicar em ambiente de testes para verificação e validação final.

A falta do wireframe/esqueleto ou pelo menos de um protótipo acarretou ao projeto X retrabalhos tanto da equipe de desenvolvimento como da equipe de testes. Algumas funcionalidades não atendiam por completo e diversas melhorias foram propostas pelo cliente, assim como problemas de usabilidade foram detectados após a construção. Caso o protótipo fosse implantado e discutido entre a equipe antes de colocar em prática o desenvolvimento, assim como foi no Projeto P, certamente o nível de retrabalho de diversas fases do projeto seria menor. Diante desse cenário, algumas melhorias foram até relacionadas como mudança de escopo, porém, o grande peso estava no retrabalho das funcionalidades que não foram completamente discutidas e analisadas entre a equipe.

Os resultados obtidos neste artigo são válidos no contexto pesquisado. No entanto, vale ressaltar que a generalização desses resultados para outros projetos e/ou organizações deve ser melhor investigado. A análise dos dados foi realizada de maneira imparcial, no entanto, convém mencionar que um dos autores do trabalho atuou como designer nos projetos, o que pode ser considerado um confounding factor do estudo.

Conclusões

Foi evidenciado que o projeto com menor índice de retrabalho foi aquele que aplicou a técnica de prototipação nas fases de Requisitos, Design, Construção e Testes, encorajando a adoção da prototipação nos próximos projetos da organização. A justificativa para tal era evitar o não cumprimento às necessidades e expectativas dos usuários e, também, a desmotivação da equipe dos projetos em decorrência de constantes retrabalhos.

Referências

Basili, V. R. (1992) Software Modelling and Measurement: The Goal/Question/Metric Paradigm. Technical Report CS-TR-2956, Department of Computer Science, University of Maryland, MD 20742.

Carrizo, D., Dieste, O., Juristo, N. (2008) Study of Elicitation Techniques Adequacy. 11º Workshop on Requirements Engineering(WER 2008), p. 104-114.

Easterbrook, S., Singer, J., Storey, M., Damian, D. (2007) Guide to Advanced Empirical Software Engineering. Springer-Verlag, Nova Iorque, Capítulo 11 – Selecting Empirical Methods for Software Engineering Research.

Leal Ferreira, S. B. e Nunes, R. R. (2008) e-Usabilidade. Rio de Janeiro: LTC, p. 19-54.

Nuseibeh, B., Easterbrook, S. (2000) Requirements Engineering: a Roadmap. Em: Proceedings of the Conference on the Future of Software Engineering (Limerick, Irlanda, junho 04-11, 2000). ICSE 2000. ACM Press, Nova Iorque.

* Allan Bessa – Analista de Sistemas e trabalha em empresa de telefonia móvel.

* Gleison Santos – Consultor em engenharia de software, professor de mestrado da Unirio e doutor em engenharia de software pela COPPE/UFRJ. [Webinsider]

Rafael Xavier Almeida

Rafael Xavier Almeida (rafaelxavier@gmail.com) - Designer, analista de projetos e trabalha em uma multinacional de TI. É mestrando em sistemas de informação pela Unirio. Twitter: @rafaelxavier.