Você está na página 1de 13

Um modelo de extensão para permitir que o

MPS.br cubra aspectos de engenharia de um


processo de desenvolvimento de software
certificado.
Everton (MSc. Candidate), Johnny (Phd)
June 2022

Abstract
Neste artigo é proposta uma extensão do Modelo de Referência para
Software do MPS.br que fornece um guiamento metodológico baseado em
Processo e Resultados Esperados, cujo objetivo é permitir a adaptação
do MPS para aplicação especializada em processos de desenvolvimento
de software crı́tico orientado à norma. São adicionados ao Modelo de
Referência do MPS o processos de Especialização (ESP) e o metaprocesso
Gestão de Resultados Especializados(GRE), bem como seus propósitos e
Resultados Esperados, cuja implementação, resulta em uma retroalimen-
tação de adaptações explı́citas ao Modelo de Referência para atender à
aspectos especı́ficos de uma norma-alvo. Uma simulação de implemen-
tação dos processos de Especialização também é mostrada, tendo como
norma-alvo a tabela de objetivos A-2 da norma DO-178C (Radio Tech-
nical Commitee for Aeronautics), comumente aceita para certificação de
software embarcado na aviação. Por fim, será proposta uma breve dis-
cussão sobre a aplicação da extensão como forma de otimizar o trabalho
de adaptação de processos para certificação.

1 Introdução
Para tornar nı́tido ao leitor o problema aqui abordado, precisamos definir e
distinguir, conceitos como Modelo, Modelo de Referência e Processo de Software,
pois, são conceitos muito próximos um dos outros e podem gerar confusão ao
tratar de um modelo de extensão, que altera um modelo de referência para
atender à um processo de software.
Segundo o [PMI21], um Modelo reflete, em menor escala, uma visão simplifi-
cada da realidade e apresenta cenários, estratégias ou abordagens para otimizar
o processo de trabalho e os esforços empregados, modelando comportamentos ou
apontando abordagens para resolver problemas. Por sua vez, [COM15] define
que um Modelo de Referência compreende definições de processos, descritos em

1
termos de propósito e resultados, junto com uma arquitetura que descreve as
relações entre os processos.
O Processo de software, conforme definido por [PRE14], compreende uma
coleção de atividades, ações e tarefas que são feitas quando um produto de
trabalho é gerado. Cada uma dessas atividades, ações e tarefas residem em
um modelo, o qual define seus relacionamentos com o processo e umas com as
outras.
Por meio das definições clássicas obtidas na literatura, é fácil perceber que
um Modelo de Referência, definido em termos de propósitos e resultados, é
algo mais abstrato que um Processo, definido em termos de ações, atividades e
tarefas, porém, como disse [PRE14], um Processo reside em um Modelo.

P rocesso
M odelo

Figure 1: Representação de Venn para definições de Modelo e Processo

Expostos aos conceitos, agora, perceba que [FD15] et all demonstraram que
não há conformidade total do modelo CMMI-DEV 1.3 com o Processo definido
pela norma DO-178C da RTCA (Radio Technical Committee for Aeronautics).
O primeiro, um Modelo de Referência, do Software Engineering Institute am-
plamente utilizado e reconhecido, o segundo, um Processo bem aceito para
certificação de software na aviação. Essa constatação, por si só, ratifica a ideia
de que nem todo Processo está dentro de um determinado Modelo e que nem
todo Modelo atende à um determinado Processo, por mais que ambos tratem
da mesma questão de Engenharia de Software, o projeto de desenvolvimento de
Software.

DO − 178C

CM M I − DEV 1.3

Figure 2: Uma representação de Venn do Estudo de [FD15]

E neste ponto já é possı́vel iniciar, de fato, a abordagem do problema que


estamos tratando aqui, pois percebemos pela figura 2 que existe uma parte do

2
Processo a qual não encontra respaldo em um determinado modelo, mesmo que
ambos tratem de questões similares, como, no caso, o projeto de desenvolvi-
mento de um software, como é o caso do CMMI-DEV e da norma DO-178C.
Seguindo, conforme observamos pela figura 2, há uma parte hachurada (em
vermelho) do Processo definido pela norma DO-178C, que não faz parte dos as-
pectos modelados pelo CMMI-DEV, ou seja, uma organização implementadora
do CMMI-DEV, muito provavelmente, não teria seu software certificado para
aviação, caso o processo de certificação utilizasse a norma DO-178C como regra
de compliance.
De forma semelhante, O MPS-SW, assim como o CMMI-DEV, também é um
Modelo de Referência para Software, porém, brasileiro, mantido pela SOFTEX
com o apoio do Governo Federal, no âmbito do Ministério de Ciência Tecnolo-
gia e Inovação e que tem como objetivo, ampliar a qualidade do processo de
software brasileiro de um amplo espectro de organizações, de nichos e tamanhos
diferentes[Sof21].
Então, perceba que a generalidade de propósito do modelo MPS, e até por
ter sido concebido baseado no CMMI-DEV, pode, também, ensejar em risco de
não compliance, devido a ausência de especialização necessária para atender ao
rigor exigido por projetos de desenvolvimento de Software Crı́ticos, por meio
de processos certificados orientados à normas, como é o caso de software para
aviação, aplicações médicas, nucleares, espaciais, etc. Em outras palavras, a
questão central aqui é se o Modelo de Referência MPS é suficiente e completo
para atender a esses tipos de desenvolvimentos e caso não seja, como o tornar
suficiente.
Logo, o objetivo desse artigo, é apresentar um estudo que está sendo con-
duzido em nı́vel de pós-graduação Strict Sensu, no qual é sugerido um Modelo
de Extensão para o MPS-SW que resolva possı́veis problemas de não compliance
causados pela inespecificidade dos processos definidos no Modelo de Referência
MPS, quando o MPS é implementado em desenvolvimentos de software crı́ticos
certificados conforme normas.
Por fim, este artigo traz também uma simulação de implementação desse
modelo de extensão, demonstrando os resultados obtidos, na aplicação do mesmo
para adaptação do MPS-SW à tabela A-2 (objetivo 1) da norma DO-178C. O
artigo está dividido em 5 seções, sendo a primeira, uma detalhada introdução,
a segunda, uma pequena fundamentação teórica da estrutura do MPS e da
norma DO-178C, o terceiro, a apresentação do modelo de extensão, o quarto,
os resultados durante a simulação de implementação do modelo e o último, as
conclusões e o estado atual da pesquisa.

3
2 Fundamentação Teórica
2.1 MPS.br
2.2 DO-178C

3 O Modelo de Extensão

Figure 3: Acoplamento da extensão ao Modelo de Referência MPS-SW

O modelo da extensão é baseado na adição de um processo de Especializa-


ção(ESP) e um metaprocesso de Gestão de Resultados Especializados e propõe
uma abordagem metodológica, orientada à resultados, com elevado nı́vel de
abstração de detalhes, essencial para distinguir um modelo de um processo
definido. Ambas as extensões propostas (ESP e GRE) foram projetadas utilizando-
se da mesma estrutura do MPS.br, compostas então por, um Processo, o Propósito
para o processo e Descrições textuais dos Resultados Esperados.

3.1 O Processo de Especialização - ESP


É definido conforme seu propósito: Conhecer e analisar os aspectos da norma-
alvo da especialização, estabelecer a correlação entre esses aspectos e os Resulta-
dos definidos no Modelo de Referência. Estabelecer um plano de especialização
em termos de adaptações(adições e expansões) de Resultados Esperados e evi-
denciar a aderência das modificações propostas ao rigor exigido pela norma-alvo.

4
3.1.1 Resultados Esperados
A norma-alvo e o nı́vel de profundidade da especialização são estabelecidos e
ESP 1 todos os documentos necessários (normas, guias, jobaid ) são conhecidos e estão
disponı́veis.
Um documento de análise de aspectos especializados é estabelecido e identifica
ESP 2
a existência de aspectos mandatórios da norma-alvo.
Uma análise de aderência/compatibilidade entre os Resultados do Modelo de
ESP 3 Referência e as necessidades impostas pelos aspectos especiais da norma é feita
e mantida.
Um mapeamento de adaptações está disponı́vel e possui rastreabilidade até o
ESP 4
aspecto da norma que o gerou.
ESP 5 Uma análise do nı́vel de maturidade mı́nima é estabelecida.
O Plano de Especialização (PSP) está estabelecido em termos de resultados
ESP 6 adicionados ou expandidos. O plano evidencia a conformidade com o rigor da
norma, o metaprocesso é definido no Plano de Especialização.
Um board de análise da extensão é formado, possui habilidades, responsabili-
ESP 7 dades e competência suficientes para aprovar os aspectos da extensão do Modelo
de Referência. O Metaprocesso é aprovado pelo board.

3.2 O metaprocesso de Gestão de Resultados Especializados -


GRE
É definido conforme seu propósito: Comunicar aos demais processos do Modelo
de Referência todas as adaptações necessárias, em termo de resultados adiciona-
dos ou expandidos
Sendo assim, os Resultados Esperados desse metaprocesso não são definidos
diretamente na Guia de Extensão, eles emergem dos resultados obtidos pela
implementação do Processo de Especialização.

4 Simulação da implementação do Modelo


Como prova de conceito, foi executada uma simulação de implementação do
modelo para adaptar o MPS.br ao rigor exigido pela tabela A-2, objetivo 1, da
norma DO-178C, a qual, no escopo do processo Software Development, deter-
mina as atividades para cumprimento do objetivo 1: High Level Requirements
are developed. O resultado da simulação, define a estrutura do metaprocesso
GRE, denominada MIL-MPS-SW, Guia Especializada para Software Militares
conformes com a Tabela A-2, objetivo 1 da DO-178C
O objetivo da simulação é verificar a completude e correção dos Resultados
Esperados para o processo de Especialização — ESP e certificar que as obje-
tivos textuais, sugerem, sem definir, atividades ao implementador que, quando
executadas levam a um arcabouço especializado. Para fins de redução de es-
copo, não foi feita a simulação para toda a norma DO-178C. Nessa seção serão
evidenciados os resultados ESP 1, ESP 2, ESP 3, ESP 4 e ESP 5 obtidos com
a execução do processo de Especialização.

5
Os resultados de ESP 6, serão parcialmente demonstrados para mostrar a
realimentação do Modelo com resultados adicionados e expandidos. O foco da
pesquisa não é, de fato, criar uma Guia de Extensão completa para a DO-178C,
mas sim, provar que o modelo e sua implementação possuem potencial para
alcançar a especialização.

Figure 4: Modelo de Extensão simulado para atender à norma DO-178C

4.1 Demonstração de Resultados Esperados ESP 1


”A finalidade da especialização é tornar os o Modelo de Referência MPS.br para
Software (MPS-SW), aderentes ao objetivo 1 da tabela A-2 da norma RTCA
DO-178C, quando aplicada ao desenvolvimento de software com Design As-
surance Level D, DAL-D. O acesso à norma foi obtido mediante parceria do
Instituto e a RTCA ”

6
4.2 Demonstração de Resultados Esperados ESP 2
MAPAEAMENTO DE ASPECTOS RELEVANTES DA NORMA-ALVO
Identificação Processos, Aspectos e
da Análise Atividades Relevantes Referência
Objetivo Processo
Especial- para o atendimento do Norma-Alvo
izada Objetivo
The system functional
and interface requeri-
ments that are allocated
HLR Requeriments A-2 Software
A2/1 to software should be P. 32, 5.1.2.a
are developed Development
analyzed for ambigui-
ties, inconsistencies and
undefined conditions
.. .. .. ..
. . . .

If parameter data items


are planned, the high-level
requirements should de-
scribe how any parameter
data item is used by the
software. The high-level
requirements should also
specify their structure, the
attributes for each of their
A2/9 P. 32, 5.1.2.j
data elements, and, when
applicable, the value of
each element. The val-
ues of the parameter data
item elements should be
consistent with the struc-
ture of the parameter data
item and the attributes of
its data elements.
Os aspectos mapeados foram identificados e tabulados, a tabela é a evidência
de cumprimento do Resultado Esperado. O termo should (deve) foi destacado,
pois, impõe um aspecto mandatório para verificação de aderência.

4.3 Demonstração de Resultados Esperados ESP 3


Este resultado é um dos mais complexos de ser obtido, pois nele, de fato, são
demonstradas as análises feitas para definir a resolução de um aspecto rastreado
e mapeado da norma-alvo.
Os aspectos mapeados foram analisados e confrontados com os Resultados
do MPS-SW em termos de relevância, aderência e grau de aderência e então

7
pré-classificados.
Os resultados foram registrados na Ficha de Compatibilidade e Aderência
(FCA) — a qual contém informações dos resultados MPS correlatos e o grau de
aderência à norma-alvo, quando a compatibilidade existe. Todas as correlações
registradas nas FCA, ou a inexistência de correlações, foram consideradas, de
forma a concluir se o conjunto de Resultados MPS correlacionados, colaborati-
vamente, ou não, é capaz de satisfazer o aspecto da norma-alvo.
Durante a simulação foram produzidas 10 FCA, das quais a FCA A2/9 e a
A2/1 foram trazidas como exemplos.

FICHA DE COMPATIBILIDADE E ADERÊNCIA


Identificação FCA A2/9
Tabela DO-178C A-2 (Software Development Process)
Objetivo: High Level Requirements are Developed
If parameter data items are planned, the high-level requirements should
describe how any parameter data item is used by the software. The high-
level requirements should also specify their structure, the attributes for
Aspecto Analisado: each of their data elements, and, when applicable, the value of each ele-
ment. The values of the parameter data item elements should be consis-
tent with the structure of the parameter data item and the attributes of
its data elements.
Referência: DO-178C, P. 32, 5.1.2.j
MPS.br
Resultado Compatibilidade Aderência Racional
INEXISTENTE
CLASSIFICAÇÃO
Classificação NÃO ENDEREÇADO
A norma apresenta um rigor explı́cito em relação à arquivos de parâmet-
Racional ros, não encontrando correlação em nı́vel de requisitos com os resultados
do Modelo de Referência do MPS.br.

8
FICHA DE COMPATIBILIDADE E ADERÊNCIA
Identificação FCA A2/1
The system functional and interface requeriments that are allo-
Aspecto Analisado cated to software should be analyzed for ambiguities, inconsisten-
cies and undefined conditions
Tabela DO-178C A-2 (Software Development Process)
Objetivo: High Level Requirements are Developed
MPS.br
Resultado Compatibilidade Aderência Racional
REQ 2 (Até Nı́vel
E) Os requisitos são
especificados, prioriza-
Passı́vel de adaptação para
dos e mantidos atu-
atender às questões de am-
alizados a partir das Aderente Adaptável
biguidade, inconsistência e
necessidades, expecta-
condições não definidas.
tivas e restrições iden-
tificadas para o pro-
duto e suas interfaces.
Parece racional que, estando
os requisitos entendidos e
analisados junto aos fornece-
REQ 3 (Até nı́vel E)
dores, problemas endereça-
Os requisitos são en-
dos pela norma, tais como:
tendidos e analisados Aderente Parcial
ambiguidade, inconsistência e
junto aos fornecedores
condições não definidas, es-
de requisitos.
tão à caminho de resolução,
mas não se pode, ainda, ter
certeza.
REQ 7 (a partir do
Nesse ponto o MPS define
Nı́vel G) Os planos,
um resultado que parece jus-
atividades e produtos
tamente tratar de aspectos da
de trabalho relaciona-
qualidade dos requisitos, im-
dos são revisados Aderente Total
pondo uma revisão de quali-
visando identificar
dade, a aderência parece total
e tratar inconsistên-
à ao objetivo da norma
cia em relação aos
requisitos
CLASSIFICAÇÃO FINAL
Classificação COLABORATIVAMENTE ENDEREÇADO
O aspecto da norma endereça de forma clara problemas como
Racional ambiguidade e inconsistência e parece que a resulação do REQ 3
e REQ 7
O escopo da classificação de compatibilidade é a análise de convergência
entre o aspecto mapeado e o resultado correlato encontrado no modelo. Quanto

9
à compatibilidade foram estabelecidas as seguintes classificações :

• Inexistente — Utilizada quando não é encontrado um resultado MPS que


trate da mesma questão de engenharia do aspecto mapeado.
• Relevante — Utilizada quando algum nı́vel de compatibilidade foi identi-
ficado, não ficando óbvia a aderência apenas pela leitura do propósito do
resultado de processo MPS e do aspecto da norma em análise.

• Aderente — Utilizada quando há uma percepção inequı́voca de que o


propósito do resultado de processo do MPS e os aspecto da norma em
análise endereçam, com algum nı́vel de aderência, a mesma questão de
engenharia. Sendo então necessário estabelecer uma classificação do nı́vel
de aderência.

Um Nı́vel de Aderência também foi estabelecido utilizando-se três gradações:


1. Parcial — Quando há evidência de compatibilidade, mas não se vislum-
bra possibilidade de adaptar o propósito do Resultado Esperado original
sem descaracterizar a definição inicial. A aderência completa poderá ser
alcançada pela união de outros resultados do modelo de referência ou de
um novo resultado proposto.
2. Adaptável — Quando há evidência de que é possı́vel adaptar, suavemente,
o texto do Resultado Esperado original sem descaracterizar ou limitar a
definição do Modelo de Referência.
3. Total — Quando há evidência clara de que o propósito do Resultado MPS
original atende totalmente à restrição imposta pelo aspecto da norma-alvo.

4.4 Demonstração de Resultados Esperados ESP 4


Na simulação, Fichas de Adaptação do Modelo (FAM), formalizaram e man-
tiveram a rastreabilidade das adaptações propostas para resolver um aspecto
previamente classificado como PARCIALMENTE ENDEREÇADO ou NÃO
ENDEREÇADO. Para adaptar o MPS à tabela A-2 objetivo 1 (High-Level Re-
quirements are developed ) da DO-178C, foram produzidas Fichas de Adaptação
para os aspectos A2/4, A2/5, A2/6, A2/7, A2/8 e A2/9. Que foram identifica-
dos e pré-classificados durante atividades que alcançaram os resultados ESP 2
e ESP 3.
O aspecto A2/9, pré-classificado pela Ficha de Compatibilidade e Aderência
FCA A2/9 foi resolvido pelas adaptações propostas na FAM A2/9, conforme
exemplo à seguir.

10
4.4.1 Exemplo de Ficha da Adaptação do Modelo

FICHA DE ADAPTAÇÃO DO MODELO


Identificação FAM A2/9
Fichas de Análise FA A2/9
Resultados MPS.br Expandidos REQ 7
Novos Resultados Adicionados 1
RESULTADOS ADICIONADOS
ESP Um documento de especificação de Itens de
Parâmetros de Dados deve ser estabelecido em ter-
ESP
mos de estruturas, atributos e valores para os itens
da estrutura, sempre que aplicável.
Aplicado em que nı́vel A partir do nı́vel G
Processo MPS.br Realimentado Engenharia de Requisitos
Parece racional que se tenha um documento que de-
Racional screva a utilização de arquivos de parâmetros e como
eles são consumidos pelo software.
RESULTADOS EXPANDIDOS
REQ 7 (a partir do Nı́vel G) Os planos, atividades
e produtos de trabalho relacionados são revisados
REQ 7
visando identificar e tratar inconsistência em relação
aos requisitos.
Modificação de Texto: Não há.
Os valores e estruturas especificadas no documento
de Itens de Parâmetros de Dados devem ser revisados
Adição de Nota
quanto a consistência entre os valores e os atributos
de cada item.
Uma vez que se tenha estabelecido um documento
para especificação de Itens de Parêmetros de Dados,
parece viável fazer também uma adaptação no REQ
Racional 7 para verificar inconsistências nos arquivos de estru-
turas. A junção dessa expansão com o resultado pro-
posto para adição, parece satisfazer completamente
o rigor da DO-178C
O aspecto A2/9, previamente classificado como NÃO ENDEREÇADO,
foi tratado pela adição de um novo resultado à ser produzido no processo MPS
de Engenharia de Requisitos à partir do nı́vel G. Além de ter sido proposta uma
expansão do resultado REQ 7, do modelo MPS original, por meio da adição de
uma nota que torna o resultado mais rigoroso quando existe um documento de
Itens de Parâmetros de Dados (Parameter data items) .

4.5 Demonstração de Resultados Esperados ESP 5


A evidência de que o resultado ESP 5 foi alcançado, durante simulação, foi
formalizada por meio da Tabela de Adaptações, na qual é apresentada a suma-

11
rização das adições e expansões propostas para tornar o MR-MPS aderente à
norma-alvo.
Na tabela, são sugeridos os textos finais para todos os resultados que sofr-
eram alterações ou que foram adicionados. Sendo então, as adições ou expan-
sões justificadas por meio das Fichas de Adaptação do Modelo, as quais mantém
visı́vel a rastreabilidade do racional envolvido em cada proposta apresentada,
de forma tal que, uma determinada modificação no MR possa ser rastreada até
a origem do aspecto da norma à que visa atender.
Abaixo é apresentada uma porção da tabela final da simulação de imple-
mentação do modelo de extensão para aderência à DO-178C (MIL-MPS-BR).
As demais FA, FCA e FAM que foram utilizadas para montagem da tabela
foram omitidas do escopo deste artigo.

MAPEAMENTO DE ADAPTAÇÕES
Código Propósito Operação Motivação
(a partir do Nı́vel G) Um documento de especificação
de Itens de Paramêtros de Dados deve ser estabele-
ESP 1 Adicionado FAM A2/9
cido em termos de estruturas, atributos e valores para
os itens da estrutura, sempre que aplicável.
REQ 7 (a partir do Nı́vel G) Os planos, atividades
e produtos de trabalho relacionados são revisados
Expandido
visando identificar e tratar inconsistência em relação
REQ 7
aos requisitos.
NOTA 1: São considerados inconsistentes requisitos que de-
screvem soluções de projeto ou detalhes de verificação, exceto Nota Adicionada FAM A2/7
quando para restrições de projeto especı́ficas e justificadas
NOTA 2: Os valores e estruturas especificadas no documento
de Itens de Parâmetros de Dados devem ser revisados quanto Nota Adicionada FAM A2/9
a consistência entre os valores e os atributos de cada item.
(a partir do Nı́vel G) Os requisitos são consistentes
FAM A2/5
ESP 2 quanto sua conformidade em relação aos padrões es- Adicionado
tabelecidos.

Table 1: Extrato da tabela de Mapeamento

5 Estado atual do trabalho


6 Discussão sobre aplicações
References
[PRE14] Roger S. PRESSMAN. “Software Engineering”. In: (2014).

12
[COM15] ISO-IEC/ INTERNATIONAL ORGANIZATION FOR STANDARD-
IZATION/ INTERNATIONALELECTROTECHNICAL COMISSION.
“ISO/IEC 33001:2015 Information Technology -Process Assessment
–Concepts and Terminology”. In: (2015).
[FD15] Alan Ferreiros and Luiz Alberto Vieira Dias. “Evaluation of accom-
plishment of do-178C objectives by cmmi-dev 1.3”. In: Proceedings
- 12th International Conference on Information Technology: New
Generations, ITNG 2015 (May 2015), pp. 759–760. doi: 10.1109/
ITNG.2015.132.
[PMI21] PMI. The Standard for Project Management and a Guide to the
Project Management Body of Knowledge (PMBOK guide). 2021,
p. 274. isbn: 9781628256642.
[Sof21] Softex. MPS.BR-Melhoria de Processo do Software Brasileiro Guia
Geral MPS de Software. 2021. url: https://softex.br/.

13

Você também pode gostar