Dados do survey destinado à indústria

Participaram da pesquisa 25 engenheiros de requisitos de vários estados do país. Por se tratar de um survey onde a identicação não era obrigatória, não sabemos precisamente quais estados participaram do estudo.

Através do reconhecimento de algumas empresas, identicamos que estas estavam si- tuadas nos estados de: Pernambuco, Ceará, São Paulo, Rio de Janeiro e Paraná. A Figura 16 demonstra melhor a visualização de algumas das regiões participantes. No survey ques- tionamos os participantes sobre alguns tópicos como processo, desaos e documentação, e sobre o tempo de experiência dos participantes com a área:

Figura 16: Desaos no ensino de documentação

• 2 deles possuíam menos de 1 ano, 11 de 1 a 5 anos, 8 de 5 a 10 anos e os outros 4 com mais de 10 anos.

• 7 dos participantes possuíam alguma especialização na área e os outros 18 ainda não.

A realização de especializações na área está bastante relacionada à ideia da busca por qualidade em todo processo. As formações costumam envolver um aprofundamento em certos temas, oferecer visões de boas práticas, alinhar conhecimentos e também compar- tilhar soluções e experiências com problemas na área. Dada a importância e o impacto da área é importante que todos que exerçam o cargo, tenham uma qualicação na área seja ela pós graduação ou certicação.

Padrões na documentação (SD01)

A padronização dos documentos é importante para que haja uma melhor organização e para reduzir o risco de que algum atributo importante seja esquecido. Muitos problemas podem partir dessa ausência de atributos e gerar custos e tempo para alteração e revisão. Pode ocorrer das empresas terem projetos de portes bastante variados e a documenta- ção ser adaptável dependendo do tamanho do projeto e de seu aprofundamento. Ainda assim, é interessante que se tenham padrões para cada porte de projeto evitando esque- cimento e auxiliando o engenheiro a manter sempre aquela referência de aprofundamento e detalhamento da documentação.

• 21 das empresas possuem padronização e as outras 4 ainda não. Processo de documentação (SD02)

Existem diferentes metodologias de desenvolvimento e a documentação pode ter seu processo incremental ou ser um item de backlog realizado em uma parte especíca do desenvolvimento e em apenas uma única vez.

• 19 empresas possuem a sua documentação sendo feita durante todo processo e ape- nas 6 possuem essa atividade feita apenas no começo do processo de desenvolvi- mento.

Vericação de documentação (SD03)

Durante o projeto os requisitos podem mudar, autores e casos de usos. Inconsistências podem ser observadas no documento. É importante que no desenvolvimento todos os requisitos devam ser implementados e vericados posteriormente. A inspeção é um método que contribui para assegurar a qualidade no sistema a ser desenvolvido. Na revisão, através de suas técnicas, os defeitos são detectados e corrigidos para que não impactem o projeto.

Tipos de documentações geradas nos projetos (SD04)

O processo de desenvolvimento envolve um conjunto de documentações. Questionamos os participantes sobre quais documentações geradas envolviam requisitos. Os documentos de Requisitos Funcionais e Não Funcionais foram quase unanimemente citados, já que eles são bastante comuns na literatura e descrevem muito sobre as funcionalidades e restrições do sistema.

Esse é um ponto bastante importante por que na academia alguns Docentes lecionam uma variedade de documentos com diagramas e atributos podendo ocorrer casos onde alguns já não são mais utilizados e outros precisem de uma maior atenção por serem mais importantes. Muitos estudantes colocam certa resistência em documentar e compreender se isso é realmente utilizado ou até quando isso é fundamental. A Figura 17 mostra o percentual de cada documentação citada.

Figura 17: Documentação gerada pela empresa

No survey foi dada a opção para que os participantes indicassem mais documentos que eram utilizados e não foram listados. Foram citados outros dois documentos: (a) Do- cumento contendo Itens de Backlog que é um checklist com as funcionalidades priorizadas desejadas para o produto e o (b) Documento de análise de pontos de função que é referente ao tamanho do projeto com base nas suas funcionalidades. Os Itens de Backlog podem ser alterados sempre que surgir um novo requisito, mas isso pode depender do tipo de método de desenvolvimento adotado.

Quantidade de horas gastas com documentação (SD05)

tinado para ela pode impactar na qualidade no produto. Ter tempo disposto para a documentação dará uma análise mais planejada, identicação de pontos de melhorias que podem impactar na redução de problemas como, por exemplo requisitos mal escritos. A Figura 18 demonstra que quase metade das empresas possuem uma média superior a 5 ho- ras para essa atividade. Lembrando que: as empresas com modelo interativo e incremental relataram a quantidade de horas relacionada a documentação na sprint.

Figura 18: Média de horas para documentação Itens presentes na documentação (SD06)

Na documentação além de descrições textuais, muitos diagramas podem auxiliar no processo de entendimento do requisito. Oferecemos no survey opções de documentos que são comumente ensinados na graduação e, além disso a opção para que o participante indicasse outras opções. A Figura 19 demonstra o percentual de citações. Além desses, ainda foram citados os diagramas de Casos de Uso (14 indicações) e de BPM (7 indicações). No primeiro foi destacado que não só o diagrama como também a descrição é fundamental, o segundo deverá ser composto das informações que um usuário precisa para conseguir realizar uma funcionalidade, disposto em forma gráca.

Disponibilidade da documentação (SD07)

A documentação de requisitos deve estar sempre disponível para consulta dos mem- bros do projeto para auxiliá-los na implementação das funcionalidades, validação e ve- ricação. Existem diferentes maneiras de disponibilizá-la. Questionamos os participantes especicamente sobre isso.

Figura 19: Artefatos listados pelas empresas

tação é disponibilizada em ferramentas. Algumas ferramentas especícas para requisitos são usadas nas empresas, outras ferramentas WEB de gerenciamento de projetos, ferra- mentas de commit (onde os requisitos são descritos nas issues tracker) e ferramentas gerais (desenvolvidas pelas próprias empresas para que cumpram essa entre outras funcionali- dades).

Em alguns casos, foi visto que a documentação é enviada por email (2 indicações), cando assim uma versão disponível na conta. Além disso, em alguns casos os artefatos do projeto incluindo os requisitos são armazenados em nuvens (5 indicações) e através de rede interna (3 indicações) das empresas onde os arquivos são disponibilizados via intranet.

Ausência de atributos (SD08)

A documentação pode variar de extensas com inúmeros atributos a simples com des- crições sucintas de funcionalidades e seus identicadores. Esse fator varia de empresa e porte do projeto. Dependendo de quem realiza essa atividade, pode acontecer de algum atributo não ser inserido na documentação. Há casos onde existe a preferência de uma documentação mais densa e outros mais simplistas. Independentemente disso, existem atributos que podem ser considerados essenciais e devem compor a documentação.

Documentação pode ser lida por diferentes membros do projeto e a presença de alguns atributo poderia ser indispensável. Por exemplo, há projetos onde o desenvolvedor quer vericar o impacto da alteração de uma especicação ou os casos de teste para uma determinada funcionalidade. Questionamos os participantes sobre a sua percepção quanto

a ausência de algum atributo e que ele o considera fundamental para o contexto da empresa.

18 participantes responderam que não sentem falta de nenhum atributo e 7 armaram da ausência, nos templates, de atributos importantes. Dentre os citados encontramos atributos que julgamos essenciais como Requisitos de Qualidade. Já havíamos visto em pesquisas recentes na literatura a demonstração de certa desvalorização em especicar esse tipo de requisito Inayat et al. (2015). Foram citados:

• Descrição do relacionamento dos requisitos com o teste na documentação • Arquitetura da solução

• Mapeamento de processos e requisitos • Requisitos de qualidade

• Regras de negócio • Rastreabilidade

• Estimativa de custo para cada requisito

Documentação disponível para o cliente (SD09)

A documentação de requisitos disponível para o cliente pode ser muitas vezes expressa de maneira mais simplista omitindo atributos que podem não fazer sentido para o cliente ou dicultar a sua visualização. Por exemplo, herança dos requisitos ou diagramas UML. Sendo assim, perguntamos sobre essa diferença na documentação entre os membros do projeto (desenvolvedores, analistas e gerentes) e o próprio cliente. Desses, 16 armam que não há diferença na documentação e 9 informaram que é diferente.

Cenários de problemas envolvendo documentação

Criamos alguns cenários que envolviam documentação de requisitos a m de veri- carmos sua ocorrência nas empresas no contexto do país. Há muitos desaos descritos na literatura e muitos estão voltados para as indústrias internacionais. Descrevemos cenários que focam em documentação por ser o contexto da pesquisa. As Figuras 20, 21, 22, 23 e 24 mostram o percentual de ocorrência de cada cenário.

No cenário 1, referente à ocorrência de problema com a falta de um requisito crucial na documentação, 12 concordam parcialmente e outros 7 concordaram totalmente com

essa armação. É importante observar que mais da metade dos respondentes passaram por esse problema dada a opção que assinalaram. Dependendo do processo de desenvolvi- mento esse pode ser um problema identicado logo no começo. Em equipes que adotam um modelo incremental, a ausência do requisito pode ser implementada na segunda rodada de implementações. O importante é perceber essa ausência antes da nalização do pro- duto. Sendo esse um requisito de uma funcionalidade que depende de outra, certamente a sua ausência será notada. Uma vez que esse seja uma funcionalidade independente, sua identicação pode não acontecer tão facilmente.

No cenário 2, referente à ocorrência de problema com requisitos que foram docu- mentados de maneira não implementável ou não evolutiva, 17 assinalaram que concordam totalmente e outros 4 concordam totalmente. Dado a natureza das constantes evoluções do mercado, os softwares devem ser planejados de maneira a também possuírem esse caráter evolutivo. Além disso, é importante que os requisitos sejam descritos de maneira imple- mentável, a não ocorrência disso pode estar associado, por exemplo, a uma deciência na atividade de especicação uma vez que possa ter ocorrido problema na escrita.

Figura 20: Cenário 1 Figura 21: Cenário 2

No cenário 3, foi questionado se a documentação é sempre entendida pelos envolvidos no projeto. Pode acontecer, por exemplo, da documentação não ter uma nomenclatura compreendida por todos, conter muitos detalhes que dicultam seu entendimento ou até mesmo ser simplicada demais. Observamos que 10 assinalaram que discordam com a armação feita, outros 5 discordam totalmente.

No cenário 4, continha a armação de que o projeto já havia enfrentado problemas com requisitos especicados incorretamente. Identicamos que 12 concordam totalmente e outros 11 concordam parcialmente. Esse é um problema muito comum e bastante de- monstrado na literatura. Há muitas soluções que são apontadas em pesquisas para reduzir sua ocorrência, porém ainda é bastante comum que as empresas ainda sofram com os im-

pactos desse problema. Por isso se faz necessário tentar atacar esse problema desde muito cedo, na academia.

Figura 22: Cenário 3 Figura 23: Cenário 4

No último cenário, 5, colocamos a armação de que os membros da equipe não têm diculdades para entender o template bem como os atributos pertencentes a documen- tação. Há inúmeros templates disponíveis e isso pode variar de acordo com tamanho da empresa, do projeto ou o próprio valor dado a essa prática. Nesta questão, 8 concordam parcialmente, 4 discordam e outros 4 mostraram-se indiferente.

Figura 24: Cenário 5 Sobre os desaos em documentar

Sabemos que a prática de documentação não é fácil e precisa dispor de tempo. Além disso, é necessário o real entendimento por parte das empresas da importância desse artefato. As questões nais do survey estavam voltadas para os desaos dessa prática.

• 21 dos participantes consideram que documentar é um desao, outros 3 acham que talvez e um participante assinalou que não (DD01)

• 14 participantes consideram que o que foi ensinado sobre documentação é desneces- sário para o contexto da empresa (DD02)

Isso nos faz reetir sobre a possível inexistência do paralelismo da academia com a indústria no que diz respeito às práticas ensinadas, a experiência que tentam passar, o conteúdo e as ferramentas que são ensinadas. É nesse ponto que retornamos o pensamento de Andrade et al. (2008) sobre a inecácia do ensino da área para os alunos seja pela desmotivação, metodologia utilizada, alto nível dos projetos e exercícios, pela falta de simulações realistas entre outros fatores.

"a maioria dos diagramas UML não são utilizados" (Sic)

Quando questionados sobre quais assuntos foram ensinados na graduação e são consi- derados desnecessários, foi quase unanimemente citado os diagramas UML. Quando não eram postos como totalmente desnecessário, era dito que a maioria deles não são utilizados em empresas.

"Diagramas de UML, até hoje não utilizei em nenhum das duas empresas que trabalhei como analista de requisitos nestes 7 anos de trabalho com requisitos" (Sic)

Outros destacaram, especicamente, que casos de uso não são muito utilizados, po- rém em contrapartida, alguns informaram que esses são essenciais. Um dos participantes relatou que o documento de requisito em si somado ao caso de uso e documento de visão são sucientes para um projeto. Outro mencionou que estórias de usuário são bastante comuns e quando bem descritas são ótimas como documentação.

Um participante levantou uma questão que, pelo visto, ainda pode ser vista nos cur- sos de graduação, a ideia de que os requisitos devem ser extensivamente documentados no começo do projeto. Tendo em vista a evolução dos modelos de desenvolvimento e o mercado de software, sabemos que isso é um argumento que não é mais tão presente em sala de aula.

Para ajudar no paralelismo da academia com a indústria, perguntamos sobre o que eles acham que deveria ser melhorado no ensino da disciplina (DD03) para que as pessoas estejam mais bem preparadas e o ensino seja mais direcionado com tópicos que mais relevantes para o meio das empresas. Estavam entre as respostas:

• Apresentar formas de documentar através de ferramentas;

• Compreender as necessidades do mercado e focar na entrega de valor ao cliente nal; • Ensino da relação do requisito com teste de software;

• Gestão de requisitos em grandes projetos de software; • Versionamento de requisitos;

• Rastreabilidade de requisitos;

• Documento de requisitos em ambiente ágil; • Melhorar o ensino sobre Casos de Uso;

• Focar em estimular a melhoria na interpretação bem como coesão textual; • Praticar mais técnicas de levantamento de requisitos e de negociação; • Usar mais estudos de casos reais em sala de aula;

• Mais abordagens práticas atrelada a teoria;

• A relação da documentação com sua utilização no desenvolvimento dos projetos; • Ensino de pontos de função;

Na pesquisa, tivemos respostas de engenheiros que em sua maioria tinham muitos anos de experiência na área. Em nossa última questão, extraímos informações sobre pro- blemas que são observados em relação aos recém ingressos (DD04). Alguns participantes responderam que não percebem algum tipo de problema por que a empresa dispõe de treinamentos imersivos que os ajudam a se adaptar ao processo da empresa e a área. Porém, os outros participantes citaram:

• Desconhecimento do padrão de documentação a ser seguido; • Desconhecimento de como descrever soluções;

• Falta de experiência e entendimento da prática de documentação; • Falta de conhecimento de UML;

• Desconhecimento do nível de profundidade da documentação; • Desconhecimento de termos do negócio;

5.5 Discussão

A análise dos dados do survey com foco na indústria nos ofereceu um cenário de diculdade e sugestões de melhorias que podem acontecer ainda na academia. A cultura de documentar existe e é importante ter essa visão. Na amostragem, muitos possuíam especialização na área o que pode signicar uma maturidade que ajuda a reduzir os desaos que são tão comumente citados na literatura e por alguns participantes.

Esse segundo survey visou oferecer o subsídio que precisamos para conseguir desen- volver um plano de aula que foque nos desaos da academia e da indústria. Vimos que muitos ainda não haviam feito especialização e acreditamos que o que foi ensinado na academia pode representar muito do conhecimento desse grupo de pessoas. Além disso, é importante lembrar que como algumas empresas investem em treinamento, essas pessoas acabam adquirindo mais conhecimento e se adaptando ao processo da empresa e sabendo como lidar com possíveis acontecimentos na área.

A padronização dos documentos foi percebida na maioria das empresas, o que é bas- tante interessante. Na academia é comum alguns questionamentos dos alunos sobre que atributos devem ter na documentação. Vimos ainda no capítulo anterior que essa variação de documentação acaba gerando um conhecimento limitando por que não é possível expli- car os diversos templates de documentação. É importante então focar em ensinar o que é comum a todos os documentos (padrões) e o que estiver fora desse escopo o aluno apren- derá na própria empresa. Também, claro, é importante ter a visão de como o mercado está realizando essa documentação.

Vimos que a maioria das empresas participantes tinha a atividade de documentação de modo incremental, além de possuírem inspeção e vericação. No cenário acadêmico, nos projetos, acontece dos alunos entregarem os documentos o mais completo possível nas primeiras entregas. Fica a dúvida se eles estão cientes do modo incremental que a documentação pode ter. Além disso, pode ser notado desinteresse dos alunos para - car vericando a documentação e atualizando-a. As inúmeras citações de desinteresse do capítulo anterior se encaixam nisso.

para fazer o paralelo com que é lecionado. Requisitos funcionais, não funcionais e de negócio lideram as citações. Na academia, comumente vemos esse tipo de documentação. Ainda mais, vimos que geralmente muitas horas são gastas com documentação. Esse fato precisa ser visto pelos alunos que costumam demonstrar incômodo e comumente realizar essa atividade de forma muito supercial. As estórias de usuário foram bastante citadas como parte da essência da documentação.

Os diagramas citados e que fazem parte da documentação são geralmente vistos em sala de aula, mas sabemos que existem casos onde os mesmos não são ensinados o que já causaria um problema do prossional ao chegar no mercado. Muitas ferramentas foram citadas e talvez deva haver uma busca pelas mais utilizadas com o intuito de trazê-las para a sala de aula e mostrar outros modos de documentar. Além do diagrama em si, é necessário ver o seu conteúdo. Como vimos anteriormente os Docentes destacaram muito problemas de interpretação e escrita.

Através dos cenários criados no survey consolidamos ainda mais a existência de proble- mas na área, já sentido pelos docentes, além de uma carência por qualidade na escrita de requisitos. A falta de requisitos no documento ocorre e isso talvez seja um reexo da não vericação da documentação e da ausência da rotina dessa atividade. Muito se armou sobre a existência de requisitos não implementáveis e não evolutivo, uma característica reexo da má interpretação e escrita. Acontece da lógica de solução estar correta, porém, a falha ocorre na transição para o documento (escrita). O entendimento da documentação - cou marcada por um meio-termo. Houve concordância quanto aos Requisitos especicados incorretamente e isso demonstra indícios de desconhecimento do negócio e inexperiência, além dos problemas de qualidade da especicação. Há ainda problemas relacionados ao entendimento dos atributos presentes na documentação, restando identicar quais foram esses atributos. Mais uma vez é rearmado que existem muitos desaos relacionados a documentação partindo do ponto de vista da academia e indústria.

Os participantes sugeriram alguns pontos que consideram que devam ser conhecidos pela academia. Os engenheiros de requisitos, da amostragem da pesquisa, identicaram em sua maioria que diagramas UML não são mais tão utilizados nas indústrias. Deve-se focar o ensino em tópicos como Histórias de Usuário e no ensino de outras formas de documentar. No capítulo anterior vimos que muitos Docentes entregam templates para os alunos e no mercado há muitos casos do uso de ferramentas para essa prática. Outros pontos foram citados e que, segundo os participantes, podem não ser aprofundados na disciplina como é o caso da relação dos testes com requisitos, versionamento e rastreabilidade.