Qualidade de processo

O que são modelos de maturidade de processos?

Os modelos de maturidade são ótimas ferramentas que permitem o conhecimento profundo dos processos, da equipe de desenvolvimento, das dificuldades, entre outros.

Fonte: Shutterstock.

Deseja ouvir este material?

Áudio disponível no material digital.

Praticar para aprender

Caro aluno, muitas vezes nós, enquanto consumidores, estamos acostumados somente a ver o produto final e não os processos envolvidos no desenvolvimento dele. A ideia é a de que, quando você vai a um fast-food, a única parte do processo com a qual você tenha contato seja o momento de fazer e receber o pedido. Seja em um fast-food, seja em um setor industrial ou, no nosso caso, na indústria do software, na grande maioria das vezes, avaliamos se o processo foi bem executado considerando o resultado que é entregue. Mas como são feitas as tratativas referentes à qualidade dos processos de desenvolvimento de software?

Inicialmente, nesta seção serão discutidos os modelos de maturidade CMM e CMMI, os quais são metodologias que visam, por meio de sua estrutura, posicionar a empresa em um nível de maturidade e, através de técnicas, planejar uma evolução em termos organizacionais a fim de promover melhoria em seus processos.

Em seguida, haverá uma discussão acerca da ISO 9001:2015, cujo foco está em utilizar metodologias que permitam aos membros da organização conhecer os processos, os microprocessos e as interações entre os componentes em sua totalidade. Dessa forma, ao se conhecer bem os processos, a chance de erros e falhas é minimizada, proporcionando a melhoria dos processos e consequentes benefícios.

O objetivo do próximo tema é que você compreenda a metodologia para melhoria de processos individuais e de equipe (PSP). Trata-se de técnicas bem fundamentadas e voltadas às pessoas (desenvolvedores), pois quem, de fato, consegue abstrair informações e codificá-las são as pessoas.

Finalmente, será apresentado o modelo de melhoria de processo de software brasileiro (MPS.BR), ferramenta muito interessante, pois permite ao desenvolvedor compreender a potencialidade do método de forma que possa ser aplicado em organizações brasileiras. Isso vem atender a uma demanda dentro da área de tecnologia da informação, na qual o MPS.BR atende as nossas especificidades.

Em termos profissionais, esses temas são de extrema importância pois são largamente utilizados dentro de organizações que buscam técnicas para atingir resultados expressivos. Dessa maneira, conhecer as técnicas e compreender o momento de aplicá-las pode ser um interessante diferencial competitivo.

A prefeitura de uma cidade litorânea em época de temporada, que compreende os meses de dezembro a fevereiro, contrata alguns profissionais temporários para limpeza, guarda-vidas, serviço de atendimento ao turista, entre outros servidores. Uma função muito importante nas últimas três temporadas foi o serviço de atendimento ao turista. Nessa função, os colaboradores ficavam grande parte do tempo ocupados em localizar os pais de crianças que se perdiam na praia.

Ocorre que, em alguns casos, a falta de um sistema integrado fazia com que esses colaboradores empregassem muito tempo para localizar os pais das crianças. Foi a partir dessa dificuldade que a prefeitura, por meio de uma concorrência pública, fez a contratação de uma empresa para desenvolver o sistema. Porém, entre as cláusulas para conseguir o contrato de desenvolvimento de software está uma classificação de maturidade dos processos a níveis aceitáveis.

Como você já possui vínculo com a prefeitura no que tange à consultoria em tecnologia da informação, no começo da semana, o prefeito da cidade solicitou-lhe um relatório técnico no qual apontasse o nível de maturidade em que a empresa contratada se encontra, para que, estando o nível de acordo, o contrato de prestação de serviço pudesse ser firmado.

A estrutura da empresa conta com parte familiar, que são os colaboradores administrativos, e parte de contratação em regime CLT, que são o gerente de projetos e demais desenvolvedores. Embora tenha uma estrutura modesta, o portfólio da empresa é interessante, pois muitas prefeituras já contrataram seus serviços de desenvolvimento.

A metodologia segue o esquema: a demanda é originada pelo gerente de projetos e os desenvolvedores realizam o trabalho. O processo de integração das partes desenvolvidas por diferentes profissionais geralmente é um pouco demorado, pois é necessário um esforço coletivo para correção de falhas e erros, além da realização de complementos e ajustes severos às vezes.

Dentro do contexto da empresa, você deverá elaborar um relatório, para o prefeito, que descreva o nível de maturidade em que a empresa está posicionada atualmente. Para isso, faz-se necessária a aplicação de um modelo de maturidade. Como sempre, o chefe do executivo espera de você um relatório com a qualidade de sempre. Mãos à obra!

conceito-chave

Caro aluno, quando você está utilizando o aplicativo para consultar sua área acadêmica, buscando informações como notas, dados pessoais, financeiros, entre outros, talvez não reflita sobre a quantidade de processos necessários para que se possa utilizar uma aplicação com confiabilidade, eficiência e segurança. Para isso, são utilizadas normas, métodos, ferramentas e metodologias que garantem a qualidade dos processos de software.

Sommerville (2015) define que, nas atividades de desenvolvimento de software, são necessários processos como uma forma de se organizar, gerenciar e compreender a ordem em que as atividades são executadas. Com o intuito de que você compreenda melhor os processos, vamos tomar como exemplo um projeto de desenvolvimento da página Home de um site. Nesse exemplo poderiam ser observados os processos: design de layout, tratamento de imagens, responsividade, entre outros. Além disso, é possível notar que cada etapa do desenvolvimento pode ser orientada por uma norma a fim de que atinja os objetivos desejados.

E por que a melhoria dos processos é importante para as atividades de desenvolvimento de software? Num primeiro momento pode parecer que a melhoria de processos só pode ser aplicada em atividades de linhas de produção, mas não é bem assim. Segundo Sommerville (2015), ao se utilizar ferramentas de qualidade de processo, a intenção é a de corrigir erros e falhas, padronizar atividades, alinhar o trabalho com a equipe de desenvolvimento, entre outros. Antes de se utilizar alguma metodologia de qualidade de processos, é necessário fazer o mapeamento deles.

Sommerville (2015) afirma que o mapeamento de processos é uma ferramenta gerencial que visa identificar a sequência na qual as atividades são executadas. Em termos práticos, o mapeamento pode gerar mais benefícios, como:

• Compreensão dos processos: permite entender todas as partes que os compõem.
• Análise dos processos: ao mapeá-los, é possível fazer uma reflexão sobre as atividades que os compõem.
• Melhoria dos processos: enxergando detalhadamente as atividades que os compõem, eles podem ser otimizados, ajustados ou substituídos, a fim de que sejam melhorados.
• Padronização dos processos: as atividades que possuem níveis de qualidade ajustados com as políticas da empresa dentro dos processos podem vir a se tornar padrão.
• Documentação dos processos: ao mapear as atividades que compõem os processos, é possível documentá-los, se assim a equipe não tiver feito nas atividades que precedem a fase de desenvolvimento do projeto.

Percebeu que antes de qualquer coisa, devem-se mapear os processos para que se compreendam detalhadamente todas as atividades de desenvolvimento? Até aqui tudo certo. Mas com que nível de detalhamento o mapeamento deve ser feito? Segundo Sommerville (2015), existem três níveis de detalhamento dos processos, conforme pode ser observado:

• Nível 1 – Descritivo: por meio de uma descrição básica e abrangente dos processos, busca-se o alinhamento deles com as partes envolvidas no projeto de desenvolvimento.
• Nível 2 – Analítico: trata-se de uma fase técnica, na qual são detalhadas as atividades de desenvolvimentos, pontos de atenção e o tratamento de exceções.
• Nível 3 – Executável: é uma visão mais próxima aos dados, à aplicação em si. Aqui a intenção é detalhar as funcionalidades, os serviços e as saídas.

Com isso, após fazer o mapeamento dos processos, seja por meio de softwares, seja por meio de descrições (textos, tabelas ou quadros), pode-se utilizar ferramentas como: modelos, normas e metodologias, os quais compõem as formas que as equipes podem utilizar para garantir a qualidade de processos de desenvolvimento de software. Dentre essas ferramentas, abordaremos incialmente os Modelos de Maturidade CMM e CMMI.

Modelos de Maturidade CMM e CMMI 

Caro aluno, as discussões acerca de qualidade de processos têm uma abrangência significativa, isso porque os processos de desenvolvimento podem ser vistos sob diversos aspectos. Para isso, inicialmente, você será conduzido às explanações acerca do grau de maturidade dos processos por meio de um modelo conhecido como CMM (Capability Maturity Model).

Segundo Couto (2007), o modelo CMM foi elaborado pelo Instituto de Engenharia de Software (conhecido por SEI – Software Engeneering Institute) da Universidade Carnegie Mellon, nos Estados Unidos da América. Para compreensão da linha do tempo do CMM, observe a Figura 2.13.

Antes de partirmos para a demonstração dos modelos de maturidade, vamos responder a uma indagação que você certamente está se fazendo: para que serve isso? Pois bem, imagine que um mesmo projeto é entregue para um grupo de programadores e para uma empresa de desenvolvimento de software. Ambos terão a mesma quantidade de profissionais, recursos computacionais e prazo. A partir disso, você pode imaginar que a entrega da empresa provavelmente será melhor. Por quê? Simplesmente porque os seus processos estão bem definidos, testados e possuem maturidade.

Segundo Couto (2007), os processos de melhoria se preocupam muito mais com a evolução dos processos que compõem as atividades de desenvolvimento do que com a agregação de novos processos ou inovações. O CMM utiliza, em sua estrutura, cinco níveis de maturidade, dentro de uma base hierárquica. Para melhor compreensão do modelo, observe a Figura 2.14.

Com base no modelo apresentado, observe o detalhamento de cada um dos níveis:

• Nível 1 (Inicial): não existe controle de processos, a equipe é guiada pelas atividades e entregas. O cliente faz a avaliação na entrega e, quando necessário, ocorrem os ajustes.
• Nível 2 (Repetitivo): nessa fase os controles de processos básicos já são utilizados nos desenvolvimentos. Porém, o mais relevante é que os processos bem-sucedidos passam a ser replicados em outros projetos.
• Nível 3 (Definido): após repetir boas práticas nos projetos, esses procedimentos são estabelecidos como padrão bem definido nas atividades de desenvolvimento. Com o tempo, passa a ser cultural entre os colaboradores.
• Nível 4 (Gerenciado): uma vez que se esteja no nível 3, momento em que já existe uma definição dos processos, é possível utilizar ferramentas de medição de estatística para efetuar o gerenciamento e o controle dos processos.
• Nível 5 (Otimização): conforme o conhecimento acerca dos processos vai aumentando e, consequentemente, o nível de maturidade, é possível repensar alguns processos, permitindo a otimização destes.

Ainda conforme define Couto (2007), os níveis de maturidade apresentam uma estrutura evolutiva, por meio da qual se busca atingir a qualidade esperada em determinado nível, para que, assim, seja possível passar ao próximo estágio e aumentar a capacidade dos processos dentro da organização.

Ainda dentro do tópico sobre modelos relacionados ao processo de desenvolvimento, porém agora com o olhar voltado para a capacidade dos processos, abordaremos o framework CMMI (Capability Maturity Model Integration). Também desenvolvido pela SEI, em 2012 foi lançada a sua última versão (1.3). O principal objetivo dessa ferramenta é analisar a capacidade da maturidade do processo de software.

Segundo Koscianski e Soares (2006), o CMMI, quando inserido na área de desenvolvimento de software, utiliza a capacidade e a maturidade para atingir metas previamente estipuladas, com nível de qualidade acordado entre as partes. Seu maior objetivo é a produção de software com o maior nível de qualidade e a menor taxa de erros.

A estrutura do CCMI é dívida em cinco níveis, os quais são utilizados para determinar a capacidade e a maturidade dos processos. Para melhor compreensão do modelo, observe a Figura 2.15.

Com base no modelo apresentado, observe o detalhamento de cada um dos níveis:

• Nível 0 (Incompleto): os processos não são executados em sua totalidade ou são parcialmente executados.
• Nível 1 (Executado): os processos conseguem satisfazer metas específicas, e a organização como um todo reconhece que existem processos definidos.
• Nível 2 (Gerenciado): nessa fase, além dos processos serem executados, existe também um monitoramento e um planejamento deles.
• Nível 3 (Definido): o processo serve como boa prática e se torna padrão dentro da organização.
• Nível 4 (Gerenciado): são utilizadas medições e técnicas de estatística para análise dos processos, o que gera, consequentemente, melhorias.
• Nível 5 (Otimizado): o foco é a melhoria contínua para a busca de melhores resultados.

Para que você compreenda o CMMI em uma situação profissional de desenvolvimento de software, observe o seguinte exemplo: o desenvolvimento do sistema web de determinada organização se dá em três partes: front end, back end e banco de dados. Ocorre que muitas vezes o tipo de dado tratado pela equipe de back end não está alinhado com o desenvolvedor de banco de dados. Ainda, ocorrem situações em que é necessária a validação dos campos tanto pelo front end (por meio do Bootstrap) quanto pelo desenvolvedor back end.

Percebeu como nesse caso, os processos de software não estão definidos? Claramente a equipe está no nível 1 do CMMI. Por meio de técnicas específicas, de planejamento e da utilização das diretrizes do CMMI, a equipe poderá visar ao próximo nível, otimizando e profissionalizando os seus processos de desenvolvimento de software.

Normas ISO de qualidade de processos 

Provavelmente você deve ter percebido, ao longo das discussões, que existem diversos modelos, normas e metodologias para todo o tipo de solução. Com a qualidade de processos não é diferente. Dito isso, você poderá compreender como a norma ISO 9001 pode auxiliar os desenvolvedores de software na busca da qualidade dos seus processos.

Segundo Valls (2003), a ISO 9001:2015 possui uma característica fundamental quanto à visão sistêmica que deve reger as atividades de desenvolvimento. Ou seja, os profissionais devem conhecer os processos, e esse conhecimento deve ser bem consistente entre os membros da organização como um todo.

Valls (2003) defende ainda que a ISO 9001 é um sistema de qualidade que visa à garantia de otimização dos processos. Essa norma também é conhecida nos meios profissionais como SQA (Sistema de Gestão da Qualidade). Para os gestores de projetos de desenvolvimento de software é um poderoso instrumento de correção e de melhoria de processos.

Conforme definido por Koscianski e Soares (2006), a ISO 9001 é estruturada por meio de oito princípios da qualidade, conforme pode ser observado a seguir:

• Foco no cliente: o pilar principal de qualquer organização deve ser o cliente, de modo que a norma orienta a busca constante das necessidades e expectativas dele. Exemplo: o cliente deseja uma aplicação mobile, porém a empresa apresenta uma “opção” de aplicação web, que é acessada por meio do navegador. Embora tenha sido apresentada uma solução (que poderia até resolver o problema do cliente), o que foi solicitado foi para uma aplicação mobile.
• Liderança: na norma existem indicativos para uma liderança que busque, com disciplina, empenho, engajamento e dedicação, os melhores resultados para a organização. Exemplo: a equipe está envolvida em um projeto cujo cliente solicita novas funcionalidades e modificações (sendo que isso estava previsto no contrato). Retrabalho pode gerar desconforto na equipe. Por meio da norma, o gestor pode reverter esse quadro.
• Envolvimento das pessoas: os desenvolvedores devem ter ciência do seu papel no projeto. Além disso, devem ocorrer treinamentos, workshops e outras atividades que otimizem o seu desempenho. Exemplo: um projeto necessita consumir uma API cujo funcionamento é pouco conhecido. A organização pode promover cursos Hands on de forma que os desenvolvedores possam atender ao projeto sem que ocorram improvisos.
• Abordagem do processo: formalizar os processos que devem ser utilizados no desenvolvimento. Gerenciar a sua correta utilização, promovendo ajustes quando necessário. Exemplo: determinado desenvolvedor acha que a construção de uma função sairá melhor fazendo do jeito dele do que utilizando o processo estabelecido na organização. Nesse caso, são necessárias algumas intervenções para ajuste de conduta.
• Abordagem sistêmica para a gestão: os processos devem ser visualizados como partes que compõem um sistema. Dessa forma, as pessoas envolvidas nos processos conseguem entender melhor o seu papel no projeto. Exemplo: imagine que exista uma equipe desenvolvendo modos de pagamento para um e-commerce. Os desenvolvedores necessitam conhecer os processos que antecedem o pagamento (escolha do produto, cesta de compras, cadastro do cliente, etc) e, ainda, os que são posteriores (retorno de confirmação de pagamento, acompanhamento de envio, etc).
• Melhoria contínua: nesse princípio, os colaboradores compreendem o detalhamento dos processos e promovem melhorias. Exemplo: determinada API, que constrói gráficos com consulta a banco de dados relacional, apresenta um atraso. Por meio de testes, a equipe descobriu que, ao se utilizar banco de dados não relacional, existe uma diminuição no tempo de consulta.
• Abordagem para tomada de decisão: os indicadores de qualidade devem permitir uma análise e oportunizar melhorias. Exemplo: ao se utilizar um software apara contagem de linhas de códigos produzidas, percebeu-se que um intervalo de cinco minutos a cada meia hora gera um aumento de produtividade.
• Benefícios: deve haver uma relação de pareceria entre as partes, de forma que possam gerar benefícios nos processos de desenvolvimento. Exemplo: uma forma de estreitar laços e conhecer os processos do cliente é alocar, por um período, na empresa, colaboradores responsáveis por mapeamento de processos e levantamento de requisitos.

Ainda de acordo com Valls (2003), ao se implantar o modelo ISO 9001:2015, deve-se: estabelecer, manter e buscar melhorias para a gestão da qualidade com ênfase nos processos e nas interações entre os microprocessos. Dessa forma, fica evidente o objetivo de se conhecer a fundo cada parte dos processos e a interação entre eles, para que não ocorra a dissociação entre os processos.

Você percebeu como a compreensão da ligação entre as partes facilita o entendimento dos processos? Além da compreensão desse aspecto, Valls (2003) afirma que, para a melhoria dos processos, as organizações devem compreender claramente os pontos a seguir:

• Entradas e saídas: todo software possui entradas e saídas. Estas devem estar bem claras desde a fase de levantamento dos requisitos, pois isso possibilita o aumento da maturidade desse ponto.
• Sequência dos processos: os processos, quando muito bem claros e estabelecidos, permitem à equipe compreender como será a sequência de trabalho. Esta deve apresentar uma lógica bem estruturada.
• Interação dos processos: o conhecimento dos processos permite a compreensão da forma e do momento em que ocorrerão as interações entre eles, permitindo, assim, o estabelecimento de pontos de atenção dentro do projeto.
• Os recursos disponíveis: não se trata apenas de recursos computacionais. Os recursos mais escassos normalmente estão ligados a prazo e a mão de obra especializada.
• As responsabilidades: cada colaborador dentro da equipe deve ter em mente sua atribuição dentro do projeto, além de conhecer os pares de interação e reconhecer as lideranças.
• Os riscos: conhecer os processos mais a fundo permite aos gestores de projetos de desenvolvimento a identificação dos riscos e dos pontos de atenção, o que reflete em ações preventivas para o cumprimento da qualidade e dos prazos.

O processo de implantação da ISO 9001 é relativamente simples e pode ser feito nas empresas independentemente do seu porte. Porém, obter o reconhecimento da aplicação 100% correta por meio da certificação ISO 9001 exige que a empresa já possua um bom nível de maturidade em seus processos de desenvolvimento de software, além de um conhecimento profundo das partes que compõem as suas normas e diretrizes.

MELHORIA DE PROCESSOS INDIVIDUAIS E DE EQUIPE (PSP)

Segundo Koscianski e Soares (2006), a sigla PSP significa Personal Software Process, cujo objetivo é promover o desenvolvimento de software com enfoque na habilidade individual dos colaboradores. Segundo o PSP, o conhecimento, a avaliação e a melhoria contínua no processo individual de desenvolvimento de software deve observar os erros e as falhas cometidas para que possam ser corrigidos e aprendidos pelo desenvolvedor.

Para exemplificar uma das formas de se operacionalizar o PSP em um projeto, pode-se utilizar a contagem de erros em código de desenvolvimento. Uma das maneiras clássicas utilizadas para esse fim é conhecida por Kloc, que tem como objetivo contar a quantidade de erros a cada mil linhas de código. Ainda segundo Koscianski e Soares (2006), o PSP é composto por quatro níveis de competência conforme pode ser observado a seguir:

• PSP 0 – Processo atual: aqui deve ser estabelecida a base da competência, que inclui a determinação dos métodos de medição, o que medir e a que momento (desenvolvimento, compilação e teste), permitindo, assim, o desenvolvimento de relatórios para análise de falhas. Nessa fase ainda deve-se desenvolver o PIP (Process Improvement Proposal), o qual, por meio de um formulário, deve registrar os problemas dos processos e sugestões de melhorias.
• PSP 1 – Estimativa de tamanho: nessa fase existem apenas dois objetivos: o planejamento do tempo e das tarefas. Trata-se de uma fase de planejamento pessoal, na qual se deve ter uma estimativa de quantas tarefas estão atribuídas ao colaborador e o tempo de desenvolvimento delas. É claro que essas medidas variam conforme o nível de competências e habilidades do desenvolvedor.
• PSP 2 – Revisão de código: o enfoque dessa fase é o processo de administração da qualidade pessoal. Nela a visão técnica da tecnologia, por meio da qual está se desenvolvendo, deve observar a aplicação dos processos estabelecidos e os resultados positivos e negativos.
• PSP 3 – Desenvolvimento cíclico: trata-se de um processo pessoal cíclico, no qual a correta aplicação dos processos, que atendem as demandas e a qualidade, seja processada em cascata, a fim de se obterem os melhores resultados.

Koscianski e Soares (2006) afirmam que as ferramentas de aferição, em conjunto com os tratamentos, fornecem curvas estatísticas que possibilitam uma análise mais profunda do desenvolvedor e ainda projeção de sua curva de evolução profissional. Porém, essa mesma técnica pode diagnosticar membros de equipe que, embora apliquem ações corretivas, insistem em não alinhar os processos de desenvolvimento.

Melhoria de Processos de Software Brasileiro (MPS.BR) 

No Brasil, nós possuímos uma ferramenta que possibilita a melhoria dos processos de softwares brasileiros. Porém, isso não significa que as suas normas sejam melhores ou piores que outras, pois estas seguem padrões internacionais de qualidade de processos. Aqui no País, a entidade que faz a gestão do MPS.BR é a Softex, responsável por apoiar a cultura da qualidade de software e por contribuir com a melhoria contínua dos processos/produto de software.

Segundo Rocha (2005), a construção das técnicas constituintes ao MPS.BR é composta pelas NBR ISO/IEC, conforme pode ser observado no esquema representado na Figura 2.16.

Para a compreensão das siglas que compõem o MPS.BR, acompanhe os tópicos a seguir: 

• Modelo de Referência (MR): contém informações a forma como a organização deve conduzir os seus processos para atingir os resultados. Ainda é possível, nesse mesmo documento, determinar o nível de maturidade e da capacidade dos processos descritos na NBR ISO/IEC 12207.
• Modelo de Avaliação (MA): trata-se do processo no qual são determinados os parâmetros e requisitos para se aferir a qualidade do desenvolvimento. É baseado na norma ISO/IEC 15504.
• Modelo de Negócio (MN): determina o nível de maturidade dos processos, que podem ser: (A) Otimizado, (B) Gerenciado, (C) Definido, (D) Largamente definido, (E) Parcialmente definido, (F) Gerenciado e (G) Parcialmente gerenciado.

Vale ressaltar que cada modelo apresenta o seu formulário específico: MR (Guia Geral e Guia de Aquisição), MA (Guia de Avaliação) e MN (Documentos do projeto). Segundo Rocha (2005), a construção das técnicas constituintes ao MPS.BR é composta pelas NBR ISO/IEC:

• NBR ISO/IEC 12207 para processo de ciclo de vida de software.
• ISO/IEC 15504 para avaliação de processo.
• ISO/IEC 15504-5 para modelo de avaliação de processo de software.

Na prática, como o MBS.BR deve ser iniciado no nível G, para o qual o manual determina 28 GPR, que são os objetivos que a equipe deve alcançar para atingir de maturidade. Observe a seguir as três primeiras GPR do nível G:

GPR 1. O escopo do trabalho para o projeto é definido; 
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados; 
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos; 

Os GPRs devem ser documentados, gerenciados e acompanhados. O modelo de documento é sugerido pelo manual, porém ele mesmo deixa flexível para que as empresas adicionem ou retirem quais campos desejar.

Caro aluno, você percebeu ao longo do texto como os métodos, normas e modelos de qualidade de processo são importantes para a área de desenvolvimento de software? Por esse motivo, é importante que esses pontos abordados sejam compreendidos e aplicados em projetos de desenvolvimento. Fica evidente que, ao utilizar tais técnicas, os resultados gerados, conforme o nível de maturidade aumenta, e as melhorias tendem a ser constantes na maioria dos processos.

Faça valer a pena

Referências

CONTROLE Estatístico de Processo – Aula 01 – Introdução ao Controle de Qualidade. São Paulo: Univesp, 2017. 1 vídeo (21 min). Publicado pelo canal UNIVESP. Disponível em: https://bit.ly/2Xg7WkH. Acesso em: 19 out. 2020.

COUTO, A. B. CMMI: integração dos modelos de capacitação e maturidade de sistemas. Rio de Janeiro: Ciência Moderna, 2007.

KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo: Novatec, 2006.

MPS.BR – Melhoria de Processo do Software Brasileiro. Guia Geral MPS de Software. Brasília: Softex, 2012. Disponível em: https://bit.ly/3oluRa5. Acesso em: 15 nov. 2020.

SOFTEX. MPS BR. Softex, Brasília, [s.d.]. Disponível em: https://softex.br/mpsbr/. Acesso em: 16 out. 2020.

SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2015.

VALLS, V. M. A documentação na ISO 9001:2000. Banas qualidade, São Paulo, v. 12, n. 133, p. 100-105, jun. 2003.