Proposta de modelagem de processos para apoiar a implementação do processo de gestão de requisitos do MPS.BR

Deivison Lamonica Barreto

deivisonlb@gmail.com

Instituto Federal de Educação, Ciência e Tecnologia Fluminense – IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brasil.

Mariane Rangel de Matos

mariane.rmatos@gmail.com

Instituto Federal de Educação, Ciência e Tecnologia Fluminense – IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brasil.

Luiz Carlos F. Garcez

luiz.garcez@gmail.com

Instituto Federal de Educação, Ciência e Tecnologia Fluminense – IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brasil.

Simone Vasconcelos Silva

simonevs@iff.edu.br

Instituto Federal de Educação, Ciência e Tecnologia Fluminense – IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brasil.

Aline Pires Vieira de Vasconcelos

apires@iff.edu.br

Instituto Federal de Educação, Ciência e Tecnologia Fluminense – IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brasil.

Alline Sardinha Cordeiro Morais

amorais@iff.edu.br

Instituto Federal de Educação, Ciência e Tecnologia Fluminense – IFFluminense, Campos dos Goytacazes, Rio de Janeiro, Brasil.


RESUMO

Destaques: A qualidade de requisitos é de grande importância para o sucesso de um software, tanto em relação ao seu funcionamento quanto aos custos envolvidos no processo de desenvolvimento. A Gerência de Requisitos é um processo importante da engenharia de software e o presente trabalho apresenta uma abordagem sobre a qualidade de requisitos com foco no Processo de Gerência de Requisitos (GRE), presente no nível G do MPS.BR (Melhoria do Processo de Software Brasileiro). O modelo de referência de software do MPS.BR traz os resultados a serem atingidos, porém são de difícil implementação por não apresentarem instruções de como atingir esses resultados. A modelagem de processos, através de modelos visuais, pode ser utilizada como um facilitador para a compreensão e execução destes resultados.

Objetivo: Este trabalho propõe a modelagem das atividades e subprocessos, através da notação BPMN (Business Process Model and Notation), necessária para atingir cada um dos resultados esperados no GRE, onde tal modelagem busca apoiar os profissionais que atuam na implementação do GRE para projetos de desenvolvimento de software.

Metodologia: Encontra-se dividida em quatro etapas: (i) Etapa I - revisão bibliográfica, (ii) Etapa II - análise documental de guias do MPS.BR, (iii) Etapa III – modelagem dos processos através da notação BPMN para a GRE no nível G do MPS.BR, e (iv) validação da modelagem proposta através de pesquisa com profissionais que atuam em áreas relacionadas a TIC (Tecnologia da Informação e Comunicação).

Resultados: A amostra de profissionais que validou os modelos propostos gerou resultados considerados satisfatórios para melhoria da compreensão das atividades necessárias para implantação da gestão de requisitos em projetos de desenvolvimento de software.

Implicações práticas: A principal contribuição prática deste trabalho é facilitar a execução dos resultados esperados do GRE.

Originalidade: a modelagem de processos é proposta como um meio visual para definir as atividades necessárias para se atingir os processos propostos em normas e/ou guias.

Palavras-chave: Engenharia de Software; Gerência de Requisitos; Qualidade; Modelagem de Processo; BPMN.

INTRODUÇÃO

O Programa de Melhoria do Processo de Software Brasileiro (MPS.BR) é um programa responsável por elaborar modelos de referência para melhoria dos processos relacionados às questões que dizem respeito aos softwares. Com isso, o programa propõe três modelos de referência melhoria do processo de software (MPS): um modelo relacionado ao processo de desenvolvimento de software, um modelo relacionado aos recursos humanos da área de TIC (Tecnologia da Informação e Comunicação), e um modelo relacionado aos serviços que apoia o modelo relacionado ao desenvolvimento de software.

O MPS.BR é um programa mobilizador, de longo prazo, criado em dezembro de 2003, coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), com apoio do Ministério da Ciência, Tecnologia e Inovação (MCTI), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID/FUMIN). O objetivo do programa MPS.BR é o aumento da competitividade das organizações pela melhoria de seus processos (SOFTEX, 2016b). Segundo Stuchi (2015), o principal objetivo do programa MPS.BR é definir modelos de melhoria e avaliação de processos.

A implantação dos modelos MPS.BR tem como principal benefício o melhoramento da qualidade dos produtos, a partir da melhoria dos processos, aumentando a competitividade da empresa em relação a outras do mesmo ramo de produção (Silva, 2013).

De acordo com a SOFTEX (2016b), os modelos de referência do MPS são: (i) MPS-SW: é o modelo para software, o qual tem como objetivo atender a necessidade de implantar os princípios de engenharia de software em conformidade com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software; (ii) MPS-SV: é o modelo para serviços, o qual foi desenvolvido para complementar o modelo MPS para Software, tanto para apoiar a melhoria de processos de serviços como para oferecer um processo de avaliação que atesta a aderência das práticas da organização em relação às melhores práticas do setor; (iii) MPS-RH: é o modelo MPS para gestão de pessoas, que tem como objetivo oferecer às organizações orientações para a implementação de práticas de gestão de RH na indústria de TIC.

Este trabalho aborda o Modelo de Referência do MPS.BR para processos de Software (MR-MPS-SW), o qual propõem 22 processos agrupados em sete níveis de maturidade. O foco, neste artigo, é no nível de maturidade inicial “G”, o qual representa o nível de maturidade “Parcialmente Gerenciado”.

Segundo Rocha et al. (2005), mesmo com o uso do modelo MR-MPS-SW e do guia de implementação, as equipes de desenvolvimento encontram dificuldades pela não existência de ferramentas de apoio à compreensão de processos do MPS.BR.

Um dos processos que apresenta dificuldades para sua correta implantação é o processo de gerência de requisitos, o qual faz parte do nível de maturidade “G”. Tal processo aborda cinco resultados que a equipe de desenvolvimento de software deve atingir para se obter maturidade.

De acordo com Aguilar et al. (2018), requisitos de software podem ser definidos como as necessidades dos clientes, os serviços que os usuários desejam que sejam fornecidos pelo sistema e as restrições sob as quais eles devem operar, sendo uma etapa de suma importância para momentos posteriores como design, implementação e avaliação do software. Esses requisitos podem sofrer alterações devido a mudanças no contexto em que o software está inserido, novas expectativas de clientes e usuários, negociação entre clientes e desenvolvedores (Sayão et al., 2003). É importante destacar que eles devem ser bem documentados, com objetivo de garantir rastreabilidade e histórico das decisões tomadas pelos envolvidos em relação ao planejamento do projeto.

Hussain et al. (2016) destacam que falhas em projetos de software geralmente são onerosas e arriscadas. Desse modo, projetos que negligenciam a engenharia de requisitos tendem a sofrer com falhas, desafios e outros riscos associados, o que representa não somente novos custos elevados, mas também perda de competitividade.

De acordo com Sayão et al. (2003), os custos de descobrir defeito na fase de testes de um software é cinco a cem vezes maior que o custo de descobrir e corrigir o problema no processo de requisitos e 50% das falhas detectadas na fase de testes são causadas por defeitos em requisitos.

Segundo Leite (2000), o processo de definir os requisitos de software é uma atividade extremamente importante e independente das outras atividades da engenharia de software, necessitando de fundamentação e processos próprios, que devem ser planejados e gerenciados ao longo de todo o ciclo de vida.

Diante desse contexto, o presente trabalho possui como objetivo propor uma modelagem das atividades, através da notação BPMN (Business Process Model and Notation), necessárias para que os resultados esperados do processo de gerência de requisitos do MR-MPS-SW sejam alcançados. Com a modelagem proposta, busca-se melhorar a compreensão dessas atividades, através de um modelo visual, e aumentar a produtividade durante a implantação desse processo.

Além dessa introdução, este artigo está organizado da seguinte forma: a seção 2 aborda a revisão bibliográfica, tratando de assuntos como qualidade de software e gestão de requisitos no MPS.BR; a seção 3 apresenta a metodologia utilizada, dividida em três fases: análise documental, modelagem visual e validação; a seção 4 apresenta os resultados da modelagem proposta, bem como os resultados de sua validação; e a seção 5 apresenta as conclusões e os trabalhos futuros.

REVISÃO BIBLIOGRÁFICA

Na revisão da literatura o tema central está relacionado a questão da qualidade e a gestão de processo.

A qualidade, segundo a ISO/IEC 9000 (2005), refere-se ao grau em que um conjunto de características inerentes a um produto, processo ou sistema consegue cumprir os requisitos inicialmente estipulados. A questão da qualidade tratada neste trabalho está direcionada para a qualidade de software, a qual se divide em qualidade do produto e qualidade do processo, sendo este último abordado neste trabalho.

Segundo Bourque e Fairley (2014), qualidade de software é uma área do conhecimento da engenharia de software que pode se referir "as características desejadas de produtos de software, a extensão em que um produto de software em particular possui essas características e aos processos, ferramentas e técnicas que são usadas para garantir essas características. Dessa forma, objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento”.

MPS.BR – MPS-SW: modelo para software

De acordo com Kalinowski et al. (2010), a melhoria constante da capacidade de desenvolvimento é algo fundamental para que empresas da área de software consigam prosperar em mercados competitivos. Isso fez com que ao longo dos anos surgissem modelos de referência para guiar a melhoria da capacidade de processos de engenharia de software. Um exemplo desses modelos é o MPS.BR.

O MR-MPS-SW possui sete níveis de maturidade, que são sequenciais e acumulativos, baseados no CMMI (Capability Maturity Model Integration). Cada um desses níveis é composto por um conjunto de processos, os quais se encontram em um determinado nível de capacidade. Os níveis de maturidade estabelecem patamares de evolução dos processos, que caracterizam etapas de melhoria de implementação de processos em uma determinada organização. Esses níveis, em ordem crescente de maturidade, são: G (parcialmente gerenciado), F (gerenciado), E (parcialmente definido), D (largamente definido), C (Definido), B (gerenciado quantitativamente) e A (em otimização) (SOFTEX, 2016b).

Neste trabalho é dada maior ênfase no nível G, que engloba o processo de gerência de requisitos. Conforme mostra o Quadro 1 (níveis do MPS.BR e seus processos), o processo de gerência de requisitos corresponde ao nível G do MPS.BR. Seu propósito é gerenciar os requisitos do produto e dos componentes do produto do projeto, identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2016b).

De acordo com Brezezinski e Gomes (2014), o objetivo do processo de gerência de requisitos é controlar a evolução do produto, gerenciar todos os requisitos recebidos ou gerados pelo projeto (funcionais e não-funcionais) e documentar os requisitos do produto e suas mudanças, processo esse que pode ser apoiado pela rastreabilidade. Segundo Gonçalves et al. (2004), um documento de requisitos é rastreável se cada uma das suas exigências (requisitos) é clara e facilitadora da identificação da mesma exigência em estágios futuros do desenvolvimento ou da documentação.

Quadro 1. Níveis do MPS.Br e seus processos

F

Fonte: Adaptado de Softex (2016b)

Segundo o guia geral MPS de Software (SOFTEX 2016b), os resultados esperados para o processo de Gerência de Requisitos (GRE) são:

• GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;

• GRE 2. Os requisitos são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido;

• GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;

• 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;

• GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

Gestão de Processos

O processo de software pode ser definido como a forma com que uma organização desenvolve seus produtos e serviços de apoio, definindo quais passos devem ser seguidos em cada fase da produção, apoiando a elaboração de estimativas, plano de desenvolvimento, medição de qualidade e o processo deve começar com os resultados esperados, desenhando estes passos para o alcance dos resultados (Lepmetz et al., 2012).

Para definição dos processos de software, alguns elementos devem ser considerados: as características da organização, as necessidades do projeto, as técnicas e métodos a serem utilizados no desenvolvimento do software, a adesão às normas e modelos de referências e as restrições de tempo e recursos.

De acordo com Mendoza e Silveira (2017), a utilização de modelos de processos de negócio pode contribuir para a especificação de requisitos de software, algo que facilita a comunicação e o entendimento do negócio entre as partes envolvidas, como gestores e projetistas de software. Segundo Esteves et al. (2015), o ser humano possui maior capacidade de captar informações através do sentido visual e, desse modo, pode ser realizada uma comunicação universal, permitindo que até mesmo pessoas externas ao processo possam compreender as informações.

Segundo Stuchi (2015), a abordagem de BPM (Business Process Model) poderia agregar muito valor à área de desenvolvimento de software. Devido a isto, foi definido o uso da notação BPMN para a modelagem dos processos deste trabalho. As notações gráficas usadas em modelagem de processos de negócio facilitam o seu entendimento, evidenciando determinados conceitos, atividades e relacionamentos, além de proporcionar condições para uma gestão colaborativa. Além da notação BPMN, outras notações podem ser utilizadas para modelagem de processos de negócio, tais como: EPC (Event-Driven Process Chain), UML (Unified Modeling Language), fluxograma, entre outras.

Trabalhos relacionados

Oliveira et al. (2010) apontam que, apesar do MPS.BR descrever um modelo de melhoria gradual dos processos de software, ele não estabelece como implementá-los. Desse modo, os autores apresentam um suíte de ferramentas de software livre de apoio à implementação dos processos do MPS.BR, chamado SPIDER – Tool Suite for Quality. Esse projeto apresenta um levantamento de ferramentas de software livre com características adequadas para possibilitar a criação de produtos de trabalhos derivados dos resultados esperados descritos nos objetivos dos processos dos níveis de maturidade G, F e E do modelo MPS.BR, que são níveis iniciais e de grande complexidade. O projeto também busca apresentar alternativas viáveis com relação a ferramentas de software para auxiliar a implementação do modelo MPS.BR nas organizações, sem a necessidade de aquisição de softwares proprietários. Além disso, a ferramenta pode ser customizada para atender as especificidades da organização, reduzindo os custos e o tempo ao longo da implementação deste programa de maturidade.

Yoshidome et al. (2012) apresentam uma proposta de apoio ferramental para a implementação do processo de Desenvolvimento de Requisitos, presente nos programas CMMI e MPS.BR, através da utilização exclusiva de ferramentas de software livre. Cabe destacar que a pesquisa se concentra no processo de Desenvolvimento de Requisitos, não abrangendo o processo de GRE. Os autores destacam que as características referentes ao processo de Desenvolvimento de Requisitos são gerenciadas de uma melhor maneira quando se sistematiza o processo a partir da utilização de ferramentas, o que tende a reduzir tempo e esforço. Desse modo, foi elaborado um fluxo de atividades utilizando BPMN, onde consta, em cada atividade, o nome da ferramenta necessária para realizá-la. De acordo com os autores, o conjunto de ferramentas livres proposto é capaz de implementar totalmente os resultados esperados do processo de Desenvolvimento de Requisitos do MR-MPS e as práticas específicas dessa área no CMMI-DEV, desde que seja utilizado de forma planejada, seguindo a metodologia apresentada pelos autores.

Cardias Junior et al. (2010) afirmam que as características referentes ao processo de GRE do modelo MPS.BR podem ser gerenciadas de uma melhor maneira quando o processo é automatizado através da utilização de ferramentas, reduzindo tempo e esforço. Para tal, é apresentada uma metodologia utilizando ferramentas de software livre. De acordo com os autores, quando estas ferramentas são utilizadas em conjunto, é possível atender à implementação do processo de GRE do modelo MPS.BR, obtendo assim, os resultados esperados desse processo. É importante destacar que a metodologia proposta pelos autores busca agregar facilidades na execução do processo, a partir do uso de ativos organizacionais através de ferramentas de software livre, sem propor a definição e institucionalização de um processo organizacional de GRE, nem substituí-lo. Os autores apontam que a análise das ferramentas apresentadas é uma proposta para implementação do processo de GRE, sendo que cada organização pode adaptá-la conforme a sua necessidade. Também é destacado que o conjunto de ferramentas utilizadas foi analisado de forma isolada e não integrada, podendo ocorrer inviabilidade de aplicação da metodologia em projetos envolvendo a alocação de recursos humanos em larga escala.

METODOLOGIA

A metodologia utilizada foi dividida em quatro etapas, conforme a Figura 1.

Figura 1. Metodologia do Trabalho

F

Fonte: Os próprios autores

Segue a descrição de cada etapa que compõe a metodologia representada pela Figura 1:

• Etapa I - revisão bibliográfica: encontra-se descrita na seção 2 deste trabalho;

• Etapa II - análise documental: elaborada através da utilização do guia geral MPS de software (SOFTEX, 2016b), com o objetivo de identificação do propósito e dos resultados esperados para o nível G do MPS.BR. Entretanto, apesar de apontar esses resultados, este guia não apresenta informações de como uma organização pode alcançá-los. Desse modo, foi utilizado também o Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS-SW (SOFTEX, 2016a), que apresenta mais detalhes para implementação do modelo. Além destes guias, também foram utilizados os trabalhos de Sayão e Leite (2005) e Stuchi (2015);

• Etapa III - modelagem dos processos: tem o objetivo de facilitar a compreensão e implementação dos resultados esperados para o processo de GRE do nível G do MPS.BR, através da elaboração da modelagem dos processos utilizando a notação BPMN. Após a análise das informações constantes no referido Guia de Implementação – Parte I (SOFTEX, 2016a), identificou-se que a utilização de material complementar tornaria a modelagem mais compreensível e foram identificadas, no guia, informações a serem utilizadas nesta modelagem. Estas informações foram divididas de modo a permitir a identificação de cada uma delas como uma atividade ou um subprocesso (conjunto de atividades). Esse procedimento ocorreu para a elaboração da modelagem referentes aos resultados esperados GRE 1, GRE 2 e GRE 5. A modelagem referente ao resultado GRE 3 foi elaborada com base no trabalho de Sayão e Leite (2005), enquanto a modelagem referente ao resultado GRE 4 foi elaborada com base no trabalho de Stuchi (2015). A modelagem para todos os resultados esperados foi elaborada utilizando a notação BPMN através do software Bizagi (2018);

• Etapa IV – validação: para verificar se os modelos elaborados são de fácil assimilação e se a utilização deles, tanto no meio acadêmico como no meio profissional, facilitaria a compreensão e implementação dos resultados esperados, foram realizadas duas pesquisas através de questionários específicos aplicados a uma amostra de profissionais que atuam em áreas relacionadas a TIC. A primeira pesquisa tem o objetivo de verificar, através do primeiro questionário, o perfil dos profissionais que compõem a amostra, onde foram solicitadas informações a respeito da experiência profissional (profissão, tempo na profissão e formação) e do conhecimento prévio em relação a modelagem de processos, notação BPMN e MPS.BR, sendo que em relação a este último foi realizado um levantamento sobre certificação, utilização dos guias e tempo de uso. A segunda pesquisa está relacionada aos profissionais que participaram da primeira pesquisa e que possuem conhecimento prévio nos temas abordados. O questionário aplicado na segunda pesquisa tem o objetivo de avaliar os modelos propostos como relação as seguintes questões: compreensão das informações apresentadas, grau de dificuldade em localizar as informações para definir as tarefas, grau de dificuldade encontrado para definição das tarefas e criação dos documentos no MPS.BR, grau de dificuldade encontrado para definição das tarefas e criação dos documentos nos modelos elaborados, grau de facilitação do entendimento das informações apresentadas nos guias do MPS.BR e como elas se relacionam. Tais questões foram analisadas de acordo com a seguinte escala: difícil, moderadamente difícil, normal, moderadamente fácil, e fácil. Além das questões elencadas acima, o questionário também proporciona a identificação de pontos positivos (facilidade em localizar a informação desejada, rapidez ao localizar as informações, linguagem simples, informações detalhadas, e possiblidade de visualizar o fluxo das informações no processo) e negativos (dificuldades em entender a modelagem utilizada e problemas com os termos utilizados) nos modelos propostos. Os respondentes tiveram a opção de não identificar nenhum ponto positivo e/ou negativo, assim como identificar pontos positivos e negativos diferentes dos citados acima. E para finalizar o questionário, foi verificado se o respondente usaria os modelos propostos para facilitar seu trabalho em relação ao uso dos Guias do MPS.BR.

RESULTADOS

Nesta seção são apresentados os modelos e a sua validação.

Modelagem dos resultados esperados do processo de Gerência de Requisitos do nível G do MPS.BR.

A primeira modelagem (Figura 2) representa uma visão generalizada do processo de GRE do nível G do MPS.BR, enquanto as demais modelagens representam os processos necessários para obtenção de cada um dos resultados esperados da GRE.

Na Figura 2, pode-se observar que cada subprocesso representa um resultado esperado do GRE, com exceção do primeiro subprocesso que representa dois resultados esperados, mostrando assim uma modelagem visual do processo como um todo. Cada subprocesso da Figura 2 será descrito através de uma modelagem detalhada das atividades para atingir cada resultado representado.

Figura 2. Modelagem dos resultados esperados GRE: visão geral

F

Fonte: Os próprios autores

A Figura 3 representa a modelagem do GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos. O fluxo de atividades proposto para se obter o resultado do GRE 1 pode ser descrito da seguinte forma: a equipe técnica coleta informações sobre os fornecedores de requisitos; define técnicas de elicitação de requisitos; realiza duas atividades em paralelo, sendo reunião com fornecedores de requisitos e a outra sendo análise de documentos; realiza reunião para registrar as informações; verifica se todos os requisitos foram entendidos, documentando os requisitos, avaliando a qualidade técnica dos mesmos, realizando nova reunião com fornecedores, se for positivo; verifica se os requisitos atendem as necessidades, registrando o aceitos dos requisitos e finalizando o processo, se for positivo; retornar para definir técnicas de elicitação de requisitos e segue o fluxo, se for negativo; retornar para definir técnicas de elicitação de requisitos e segue o fluxo, se for negativo.

Para melhor compreensão das demais figuras, é preciso analisá-las com a mesma forma de descrição utilizada para a Figura 3. Desta forma, a Figura 4 representa a modelagem do GRE 2, a Figura 5 representa a modelagem do GRE 3, a Figura 6 representa a modelagem do GRE 4, e a Figura 7 representa a modelagem do GRE 5.

Figura 3. Modelagem do GRE 1.

F

Fonte: Os próprios autores

Figura 4. Modelagem do GRE 2.

F

Fonte: Os próprios autores

Figura 5. Modelagem do GRE 3.

F

Fonte: Os próprios autores

Figura 6. Modelagem do GRE 4.

F

Fonte: Os próprios autores

Figura 7. Modelagem do GRE 5.

F

Fonte: Os próprios autores

Validação da modelagem proposta

Na primeira pesquisa, o questionário elaborado com o objetivo identificar o perfil dos respondentes foi encaminhado para uma amostra aleatória de 32 profissionais que atuam na área de TIC, desta amostra foi obtido 75% de retorno.

Em relação ao perfil dos respondentes, 100% afirmaram que conhecem modelagem de processos; 83,30% conhecem a notação BPMN; 83,30% conhecem o MPS.BR, mas apenas 16,70% o utiliza no trabalho. Nenhum dos respondentes possui certificado MPS.BR. Em relação a profissão, 100% são professores universitários, sendo que destes 60% já trabalharam como consultores na área de processos e/ou qualidade. A maioria da amostra possui mais de dez anos de experiência, 40% são doutores e 60% são mestres em áreas relacionadas a TIC.

A segunda pesquisa ocorreu com 80% da amostra que retornou as informações sobre o perfil, pois foram selecionados apenas aqueles que continham conhecimento em modelagem de processos, notação BPMN e MPS.BR.

A Figura 8 apresenta as principais questões realizadas em relação à avaliação dos modelos e os resultados encontrados.

Figura 8. Resultado da avaliação das modelagens propostas

F

Fonte: Os próprios autores

Pela Figura 8 pode-se observar que, em relação a amostra utilizada na pesquisa, a “compreensão das informações apresentadas” e a “dificuldade em localizar as informações para definir as tarefas” foram consideradas fáceis pela maioria; a “definição das tarefas e criação dos documentos no MPS.BR” foi considerada de fácil a moderadamente difícil; a “definição das tarefas e criação dos documentos nos modelos elaborados” foi considerada de fácil a moderadamente fácil; e foi considerado de fácil a moderadamente fácil a questão dos modelos propostos para atingir o objetivo de facilitar a compreensão das informações apresentadas nos guias do MPS.BR e a relação entre elas. A Figura 9 apresenta os pontos positivos apontados pela amostra.

Figura 9. Pontos positivos apontados pela amostra

F

Fonte: Os próprios autores

Na Figura 9 pode-se observar que os pontos positivos mais apontados pela amostra em relação aos modelos propostos foram a “linguagem simples” e a “possibilidade de visualizar o fluxo das informações no processo”. Alguns respondentes sugeriram como outro ponto positivo dos modelos propostos a “compreensão visual de todo o processo”.

Para 83% da amostra, os pontos negativos em relação aos modelos propostos não foram identificados e para 17% da amostra, os modelos propostos apresentam como ponto negativo a necessidade de conhecer a notação BPMN para entender o modelo.

Desse modo, observando os resultados obtidos através da aplicação dos questionários, pode-se constatar que os modelos elaborados atingiram o seu objetivo, visto que a maioria dos quesitos referentes a eles foi avaliada como “fácil” ou “moderadamente fácil”.

Um ponto importante a ser destacado é que 100% dos respondentes informaram que usariam os modelos propostos para facilitar o trabalho de utilização dos guias do MPS.BR.

CONCLUSÕES

Através do presente trabalho foi elaborada a modelagem dos processos, com o objetivo de facilitar a compreensão e a implantação das atividades necessárias para obtenção dos resultados esperados do processo de GRE do nível G do MPS.BR. Foram elaborados seis modelos, sendo que o primeiro representa uma visão geral do GRE do nível G do MPS.BR, o qual é detalhado através dos demais modelos, onde cada modelo representa um resultado esperado desse processo.

Tendo em vista as respostas obtidas na validação, pode-se concluir que a principal contribuição deste trabalho está na proposta da utilização de modelos visuais, como a modelagem de processos através da notação BPMN utilizada, a qual pode auxiliar a compreensão das atividades necessárias para que cada resultado esperado seja obtido. Assim, a modelagem elaborada pode ser utilizada como uma espécie de roteiro a ser seguido, não indicando somente quais são os objetivos, mas principalmente, identificando quais as atividades são necessárias no caminho a ser percorrido para que os resultados sejam alcançados.

Um fator limitador deste trabalho refere-se ao tamanho da amostra, o qual é considerado pequeno. Desse modo, para trabalhos futuros sugere-se uma nova validação com um tamanho mais significativo de amostra com o objetivo de obter resultados mais expressivos.

Ainda para trabalhos futuros, sugere-se a ampliação da metodologia proposta para os demais processos de todos os níveis do MPS.BR no modelo de referência para software. Desse modo, seria possível demonstrar através de uma modelagem visual as atividades e subprocessos necessários para os resultados esperados e todos os processos, tornando mais fácil o entendimento e a implementação do MR-MPS-SW.

REFERÊNCIAS

Aguilar, J.A. et al. 2018. A Survey About the Impact of Requirements Engineering Practice in Small-Sized Software Factories in Sinaloa, Mexico. In: Gervasi, O. et al. (Orgs.). Computational Science and Its Applications 10963, 331-340. https://doi.org/10.1007/978-3-319-95171-3_26

Bizagi. 2018. https://www.bizagi.com/pt/produtos/bpm-suite/modeler

Bourque, P.; Fairley, D. 2014. SWEBOK 3.0 Guide to the Software Engineering Body of Knowledge. [S.l.]: IEEE Computer.

Brezezinski, T., Gomes, M.C. 2014. Uma abordagem para a criação da especificação de requisito e caso de teste no modelo MPS.BR nível G. Tecnologias em Projeção 5, 2:26–40.

Cardias Junior, A.B. et al. 2010. Uma Análise Avaliativa de Ferramentas de Software Livre no Contexto da Implementação do Processo de Gerência de Requisitos do MPS.BR. WER.

Esteves, R.R. et al. 2015. Aplicação da Gestão Visual como Ferramenta de Auxílio para o Gerenciamento de Projetos de Arquitetura e Engenharia em uma Universidade Pública. Revista de Gestão e Projetos 3, 3:71–83. https://doi.org/10.5585/gep.v6i3.367

Gonçalves, A. et al. 2004. IEEE Std 830 - Prática recomendada para especificações de exigências de software, abril, 42.

Hussain, A. et al. 2016. The Role of Requirements in the Success or Failure of Software Projects. International Review of Management and Marketing, 6, 7S:306-311. https://econjournals.com/index.php/irmm/article/view/3272/pdf

ISO/IEC. The International Organization for Standardization and the International Electrotechnical Comission. 2005. ISO 9000: Quality management systems – Fundamentals and vocabulary, Geneve: ISO (https://prezi.com/zvpaoydvj6vx/norma-isoiec-25000-square/).

Kalinowski, M. et al. 2010. MPS.BR: Promovendo a Adoção de Boas Práticas de Engenharia de Software pela Indústria Brasileira. https://www.softex.br/wp-content/uploads/2015/09/CIBSE2010_MPSBR_CameraReady1.pdf

Leite, J.C. 2000. Análise e especificação de requisitos. Notas de aula.

Lepmetz, M. et al. 2012. Goal alignment in process improvement. The Journal of Systems and Software 85, 6. https://doi.org/10.1016/j.jss.2012.01.038

Mendoza, V.Y., Silveira, D.S. 2017. Verificando a compreensão do BPMN com gestores de negócio. Revista Brasileira de Computação Aplicada 9, 4:60-75. https://doi.org/10.5335/rbca.v9i4.7076.

Oliveira, S. et al. 2010. SPIDER – Um Suite de Ferramentas de Software Livre de Apoio à Implementação do Modelo MPS.BR. https://www.enacomp.com.br/2010/anais/artigos/resumidos/enacomp2010_43.pdf

Rocha, A.R. et al. 2005. Dificuldades e Fatores de Sucesso na Implementação de Processos de Software Utilizando o MR_MPS e o CMMI. https://www2.unifap.br/furtado/files/2017/04/007.pdf

Sayão, M. et al. 2003. Qualidade em Requisitos. Monografias em Ciências da Computação, n° 47/03. Rio de Janeiro: PUC. file:///C:/Users/carin/Downloads/03_47_sayao.pdf

Sayão, M.; Leite, J.C.S.P. 2005. Rastreabilidade de Requisitos. Monografias em Ciências da Computação, n° 20/05. Rio de Janeiro: PUC. http://www.dbd.puc-rio.br/depto_informatica/05_20_sayao.pdf

Silva, D. 2013. O que é o MPS-Br? http://www.blogdaqualidade.com.br/o-que-e-o-mps-br/

SOFTEX. 2016a. Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS-SW:2016. https://www.softex.br/wp-content/uploads/2016/04/MPS.BR_Guia_de_Implementacao_Parte_1_2016.pdf

SOFTEX. 2016b. Guia Geral do MPS de Software. https://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2016.pdf

Stuchi, R. B. 2015. Mapeamento de ontologias empresariais para modelos de processos de negócio em BPMN, com aplicação em processos de software. Dissertação, Universidade Estadual Paulista - UNESP, São José do Rio Preto, SP.

Yoshidome, E. et al. 2012. Um apoio Sistematizado à Implementação do Processo de Desenvolvimento de Requisitos do MPS.BR e CMMI a partir do Uso de Ferramentas de Software Livre. http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER12/paper_9.pdf


Recebido: 15 maio 2020

Aprovado: 02 nov. 2020 ** DOI:** 10.20985/1980-5160.2020.v15n3.1637

Como citar: Silva, S.V.; Barreto, D.L.; Matos, M.R. et al. (2020). Proposta de modelagem de processos para apoiar a implementação do processo de gestão de requisitos do MPS.BR. Revista S&G 15, 3, 263-276. https://revistasg.emnuvens.com.br/sg/article/view/1637