UNIJUÍ – UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL
DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO
DE CASO COM NÍVEL G DO MPS.BR EM UMA
EMPRESA DE PEQUENO PORTE
DIOGO FRITZEN KALB
Ijuí – RS Julho/2014
DIOGO FRITZEN KALB
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO
DE CASO COM NÍVEL G DO MPS.BR EM UMA
EMPRESA DE PEQUENO PORTE
Projeto de Pesquisa Final do Curso de Ciência da Computação do DCEEng – Departamento de Ciências Exatas e Engenharia da UNIJUÍ – Universidade Regional do Noroeste do Estado do Rio Grande do Sul, apresentado como
requisito para a aprovação no
componente curricular Trabalho de Conclusão de Curso.
Orientador: Msc. Romário Lopes Alcântara
Ijuí – RS Julho/2014
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO
DE CASO COM NÍVEL G DO MPS.BR EM UMA
EMPRESA DE PEQUENO PORTE
DIOGO FRITZEN KALB
Projeto de Pesquisa Final do Curso de Ciência da Computação do DCEEng – Departamento de Ciências Exatas e Engenharia da UNIJUÍ – Universidade Regional do Noroeste do Estado do Rio Grande do Sul, apresentado como requisito para a aprovação no componente curricular Trabalho de Conclusão de Curso.
______________________________________ Orientador: Prof. Msc.Romário Lopes Alcântara
BANCA EXAMINADORA:
______________________________________ Prof. Msc. Marcos Ronaldo Melo Cavalheiro
Ijuí Julho/2014
Dedico esse trabalho a minha amada família.
AGRADECIMENTOS
Meus sinceros agradecimentos a todos aqueles que de alguma forma doaram um pouco de si para que a conclusão deste trabalho se torna-se possível:
A Deus, o centro e o fundamento de tudo em minha vida, por renovar a cada momento a minha força e disposição e pelo discernimento concedido ao longo dessa jornada.
Aos meus pais, Armindo Kalb e Loiva Salete Fritzen Kalb que com muito carinho e apoio, não mediram esforços para que eu chegasse até esta etapa da minha vida.
Ao meu professor Orientador Msc. Romário Lopes Alcântara, pelo auxílio, disponibilidade de tempo e material, sempre com uma simpatia contagiante e pelo fornecimento de material para pesquisa do tema.
A todos os professores do curso, que foram importantes na minha vida acadêmica e no desenvolvimento deste trabalho.
Aos amigos e colegas, pelo incentivo e pelo apoio constante.
E a todos que direta ou indiretamente fizeram parte da minha formação!
“Os nossos pais amam-nos porque somos seus filhos, é um fato inalterável. Nos momentos de sucesso, isso pode parecer irrelevante, mas nas ocasiões de fracasso, oferecem um consolo e uma segurança que não se encontram em qualquer outro lugar” (Bertrand Russell).
RESUMO
A fundamental finalidade do trabalho foi descrever e debater a implantação de um modelo de melhoramento no processo de software em uma empresa de pequeno porte, e o modelo a ser usado será MPS.BR – Melhoria de Processo de Software Brasileiro. A empresa escolhida buscou inserir o MPS.BR para poder mobilizar todos os colaboradores para ter um melhor entendimento e também uma melhoria em todos os softwares desenvolvidos e consequentemente satisfação dos seus clientes. O modelo foi escolhido por ter um valor baixo e por aperfeiçoar o método de software de uma forma gradual. O entendimento de alguns conceitos como os de engenharia, qualidade de software e a melhoria de processos de software tornou-se eficaz para elaborar o mesmo. O modelo se mostrou viável para a implantação de avanços de forma gradual e voltado a realidade da empresa.
Palavras-Chave: MPS.BR. Processo de Software. Qualidade de Software.
ABSTRACT
The fundamental purpose of the study was to describe and discuss the implementation of a model of the software process improvement in a small-sized company, and the model to be used will be MPS.BR - Improvement of Brazilian Software Process. The company sought to enter the chosen MPS.BR to be able to mobilize all employees to have a better understanding and also an improvement in all developed software and hence customer satisfaction. The model was chosen to have a low value and improve the software method in a gradual manner. The understanding of some concepts such as engineering, software quality and process improvement software became effective for preparing the same. The model was feasible to deploy advances gradually and facing the reality of the company.
LISTA DE ABREVIATURAS E SIGLAS
AI: Artificial Intelligency
CMMI: Capability Maturity Model Integration ETM: Equipe Técnica do Modelo
FCC: Fórum de Credenciamento e Controle IEC: International Electrotechnical Commission IEE: Institute of Electrical and Engineers
ISO: International Organization for Standardization ITIL: Information Technology Infrastructure Library
MA.MPS: Método de Avaliação da Melhoria do Processo de Software MPS.BR: Melhoria do Processo de Software
MR.MPS: Modelo de Referência da Melhoria do Processo de Software PRM: Process Reference Model
RUP: Rational Unified Process
SOFTEX: Associação para Promoção da Excelência do Software Brasileiro TI: Tecnologia da Informação
LISTA DE FIGURAS
Figura 1: Engenharia de software ... 19
Figura 2: Modelo em cascata ... 21
Figura 3: Diagrama do modelo espiral ... 22
Figura 4: Fases do processo unificado (RUP) ... 25
Figura 5: Elementos chave do TQM ... 26
Figura 6: Componentes da estrutura do CMMI-DEV ... 31
Figura 7: Componentes do programa MPS.BR ... 34
LISTA DE TABELAS
Tabela 1: Características do processo ... 29
Tabela 2: Níveis da ISO/IEC 15504 ... 38
Tabela 3: Níveis de maturidade do MR-MPS ... 44
Tabela 4: Custos níveis MPS-BR ... 50
SUMÁRIO 1 INTRODUÇÃO ... 13 1.1 JUSTIFICATIVA ... 14 1.2 OBJETIVOS DO ESTUDO ... 15 1.2.1 Objetivo Geral ... 15 1.2.2 Objetivos Específicos ... 15 2 ASPECTOS GERAIS DO MPS.BR ... 16 2.1 SOFTWARE ... 16 2.2 PRINCIPAIS APLICAÇÕES ... 17 2.2.1 Software Básico ... 17
2.2.2 Software de Tempo Real ... 17
2.2.3 Software Comercial ... 17
2.2.4 Software Científico e de Engenharia ... 18
2.2.5 Software Embutido ou Embargado ... 18
2.2.6 Software de Computador Pessoal ... 18
2.2.7 Software de Inteligência Artificial ... 18
2.2.8 Software Online ... 18
2.3 ENGENHARIA DE SOFTWARE – CONCEITOS E ASPECTOS ... 19
2.3.1 Paradigmas de Engenharia de Software ... 20
2.3.2 Modelos de Processo de Desenvolvimento de Software ... 20
2.3.2.1 O Modelo em Cascata ... 20
2.3.2.2 Modelo Espiral ... 21
2.3.2.3 Modelo de Prototipação ... 23
2.3.2.4 O Modelo RUP ... 23
2.4 QUALIDADE DE SOFTWARE ... 25
2.4.1 Garantia da Qualidade do Software ... 27
2.4.2 Melhoria do Processo de Software ... 27
2.5 MODELO DE QUALIDADE DE SOFTWARE ... 29
2.5.1 Modelo CMMI ... 30
2.5.2 Modelo ISO/IEC 9126 ... 31
2.5.3 Modelo MPS ... 33
3 PROJETO MPS.BR ... 34
3.1 BASE TÉCNICA PARA A DEFINIÇÃO DOS COMPONENTES DO MPS.BR ... 35
3.1.1 ISO/IEC 12207:2008 ... 35
3.1.3 ISO/IEC 20000 ... 39
3.1.4 MPS.BR e suas Estruturas de Apoio ... 40
3.2 DESCRIÇÃO DOS MODELOS MPS ... 40
3.2.1 Descrição do Modelo de Referência MR-MPS ... 40
3.2.2 Descrição do Modelo de Avaliação MA-MPS ... 41
3.2.3 Descrição do Modelo de Negócio MN-MPS ... 41
4 PROCESSO MPS.BR ... 42
4.1 CAPACIDADE DO PROCESSO ... 42
4.1.1 Atributos de Processo ... 43
4.1.2 Exclusão de Processos ... 44
4.2 NÍVEIS DE MATURIDADE ... 44
4.2.1 Nível G – Parcialmente Gerenciado ... 45
4.2.2 Nível F – Gerenciado ... 46
4.2.3 Nível E – Parcialmente Definido ... 47
4.2.4 Nível D – Largamente Definido ... 48
4.2.5 Nível C – Definido ... 48
4.2.6 Nível B – Gerenciado Quantitativamente ... 49
4.2.7 Nível A – Em Otimização ... 49
4.3 CUSTOS ... 50
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE CASO COM NÍVEL G DO MPS.BR EM UMA EMPRESA DE PEQUENO PORTE ... 51
5.1 TIPO DE PESQUISA ... 51
5.2 PROCESSOS METODOLÓGICOS ... 51
5.3 DEFINIÇÃO DA EMPRESA ... 52
5.4 PROCESSO ATUAL... 52
5.5 IMPLEMENTAÇÕES ... 53
5.6 RESULTADOS ESPERADOS COM A IMPLEMENTAÇÃO ... 53
5.7 RESULTADOS ALCANÇADOS ... 55
5.8 ANÁLISE DA IMPLEMENTAÇÃO ... 57
5.9 DIFICULDADES ENCONTRADAS NA IMPLEMENTAÇÃO ... 58
6 CONCLUSÃO ... 59
7 TRABALHOS FUTUROS... 61
8 REFERÊNCIAS BIBLIOGRÁFICAS ... 62
1 INTRODUÇÃO
A melhoria de processos de software em empresas brasileiras tem ocorrido cada vez mais em consonância com o modelo de Melhoria do Processo de Software Brasileiro (MPS.BR) (SOFTEX, 2009).
Estudos indicam que dentro do âmbito das empresas de software brasileiras, empresas que se certificam em programas de qualidade têm maior possibilidade de exportar e também de ocupar o mercado interno (IPEA, 2006).
O MPS.BR (Melhoria do Processo de Software Brasileiro) apresenta seus principais atributos baseados no SOFTEX o qual é responsável por agenciar a qualidade de software no Brasil, responsável por alterar o perfil do software nacional, que está se desenvolvendo em outros países.
Hoje em dia são muitos os modelos de avanço de processo de software disponíveis, entre eles se destacam: CMMI, ISO 15504, ISO 12207, ISO 20000 e o modelo brasileiro MPS.BR o qual se adapta ao fato de diferentes empresas com abordagem nas micro, pequenas e médias. O que todos têm em comum é a procura da qualidade nos processos, o que normalmente implica no avanço da qualidade de seus produtos.
Segundo Travassos e Kalinowski (2009, p. 27), os resultados de desempenho de organizações que seguiram o MPS.BR indicam que estas empresas obtiveram maior satisfação dos seus clientes, maior produtividade, capacidade de desenvolver projetos maiores e satisfação com o MR-MPS.
As organizações tentam implementar o MPS.BR com a finalidade principal de garantir e também planejar que o começo dos projetos sejam cumpridos, com isso os sistemas de qualidade alcançam o avanço contínuo de seus produtos e serviços, pensando nisso vamos trabalhar com o modelo MPS.BR focando a prática do Nível G.
Este trabalho tem como foco principal o modelo de melhoria e avaliação do processo de software, aplicando-se em uma empresa de pequeno porte da área de desenvolvimento de software, levando em consideração os níveis de implantação para poder ter uma melhor compreensão dos conceitos e com isso um melhor entendimento dos envolvidos na implementação do MPS.Br nível G.
A parte inicial deste trabalho, se dá pela apresentação da justificativa que visa explicar a importância e para que é interessante esta pesquisa. Seguida dos objetivos que busca-se atingir com a referente indagação.
No segundo capítulo, Aspectos Gerais do MPS.Br busca conceitos e teorias necessárias para melhor entendimento deste tema, tais como: software e suas principais aplicações, engenharia do software, qualidade do software, modelo de qualidade de software, projeto MPS.BR, descrição do MR-MPS-SW, níveis de maturidade.
Após o referencial teórico, apresenta-se o tipo de pesquisa, e por fim, a caracterização da empresa, processo atual, implementações, resultados e dificuldades.
1.1 JUSTIFICATIVA
Segundo Softex (2005), tendo em vista a contribuição com soluções para o cenário brasileiro da qualidade de software, o projeto MPS.BR (Melhoria do Processo de Software Brasileiro), continua se desenvolvendo desde 2003, por sete grandes instituições, com capacidade complementares no avanço de processo de software, que procura constituir um padrão de software fundamentado em guias que ajudam para a avaliação da qualidade do produto.
Com o custo muito alto dessas certificações muitas vezes tornasse inviáveis a empresas de micro, médio e pequeno porte, por meio de um acordo entre a Softex, o Governo e Universidades teve início o projeto MPS-BR (Melhoria do Processo de Software Brasileiro) o qual é uma solução brasileira ajustada com o modelo internacional CMMI, mas elaborada com base na realidade brasileira.
Dando a oportunidade para as empresas que trabalham com desenvolvimento de software a seguir o modelo MPS-BR e apresentar um diferencial no competitivo mercado, conseguindo essa certificação com um reduzido custo se for comparada com as normas estrangeiras, o modelo MPS-BR está tendo amplo desenvolvimento nos últimos anos chegando nos países próximos como Peru, Chile, Argentina, Costa Rica, e Uruguai. O Brasil é um dos países que o desenvolvimento de software no mundo é um dos maiores, o que faz com que mais e mais clientes querem produtos de melhor qualidade e cada vez mais complexos.
1.2 OBJETIVOS DO ESTUDO
1.2.1 Objetivo Geral
O objetivo do trabalho é a implantação do melhor processo de desenvolvimento em uma empresa de porte pequeno usando o modelo descrito no MPS.BR. Com essa implantação a empresa tem a expectativa de conseguir um avanço expressivo na qualidade de seus softwares, uma significativa melhora no gerenciamento de projetos e, conseguindo assim um aumento no número de clientes.
Foi escolhido o modelo MPS.BR nível G, por se adaptar aos padrões brasileiros, tendo como proposta aperfeiçoar o processo de software.
1.2.2 Objetivos Específicos
Por meio da fundamentação teórica, esperamos conseguir base para poder desenvolver o tema escolhido neste estudo, revisando a parte teórica estudada para o desenvolvimento do Trabalho de Conclusão e o emprego da própria para avaliação dos problemas, ficando assim desenvolvido por meio de uma análise profunda, abrangendo o desenvolvimento de software, condições de avaliação para adaptar a característica do processo de software, melhoramentos, custos, geração de negócios novos e também suas vantagens e desvantagens.
2 ASPECTOS GERAIS DO MPS.BR
2.1 SOFTWARE
Conforme Cândido (2004, p. 75), no começo deste século, fatores como a globalização da economia e a maior concorrência do mercado têm gerado inúmeros desafios para as empresas. No fato dessas empresas serem baseadas em desenvolvimento de software, criar sistemas em tempo hábil, com valores plausíveis e qualidade adequada tornou-se essencial.
A qualidade no método influencia inteiramente na obra final. Um método de software desordenado demostra a ausência de qualidade e organização da empresa responsável pelo desenvolvimento do software.
Na atualidade são muitos os métodos de melhoria de processos de software no mercado, os que mais se sobressaem são: ISO15504, ISO12207, CMMI e o modelo MPS-BR o qual é brasileiro. Eles têm em comum a procura da qualidade nos métodos, o que provoca a melhora dos produtos.
Ao passar do tempo, ninguém imaginava que o software tornaria um elemento muito importante para o mundo e teria a capacidade de manipular a informação. Com muitos elementos computacionais tiveram mudanças até hoje e continuam tendo. Com este crescimento computacional, levam a criação de sistemas perfeitos e problemas para quem desenvolve softwares complexos. As preocupações dos engenheiros de software para desenvolverem os softwares sem defeitos e entregarem estes produtos no tempo marcado, assim leva a aplicação da disciplina de engenharia de software. Com o crescimento desse segmento muitas empresas possuem mais especialistas em TI em que cada um tem sua responsabilidade no desenvolvimento de software e é diferente de antigamente que era um único profissional de software que trabalhava sozinho numa sala (PRESSMAN, 2007, p. 39).
Conforme dados de Significados (2011, p. 16), os software podem ser classificados em três tipos:
- software de sistema: é o conjunto de dados processadas pelo sistema interno de um computador que permite a interação entre o usuário e os periféricos por meio de uma interface gráfica;
- software de programação: é o conjunto de ferramentas que permitem ao programador desenvolver sistemas utilizando linguagens de programação e um ambiente para o desenvolvimento;
- software de aplicação: são programas que permitem ao usuário executar uma série de serviços característicos de diversas áreas.
2.2 PRINCIPAIS APLICAÇÕES
2.2.1 Software Básico
Segundo Pressman (2007, p. 34), define-se como um conjunto de programas que dão base a outros programas. As qualidades marcantes desta categoria de software são: a intensa interação com o hardware e compartilhamento de recursos, uso constante de processamento concorrente, que demanda o escalonamento, e estruturas de dados muito complexas. Temos como exemplo compiladores, editores de texto, sistemas operacionais.
2.2.2 Software de Tempo Real
Para Pressman (2007, p. 35), essa categoria caracteriza por monitorar, avaliar e controlar fatos do mundo real. Existem elementos típicos como: Coleta de dados do ambiente externo, Análise que transforma a informação de acordo com a necessidade do sistema, controle e saída para o ambiente externo e um componente de monitoração que coordena todos os outros. Lembrando que tempo real caracteriza-se por responder dentro de restrições de tempo exatas. Temos como exemplo nas aeronaves os controles de navegação, nos automóveis os sistemas de injeção eletrônica.
2.2.3 Software Comercial
Conforme Pressman (2007, p. 35), essa categoria é a maior área privada de software. Nela os dados são reunidos de uma forma que facilite as operações comerciais e as decisões administrativas, usando ainda métodos de computação interativa. Temos como exemplo controle de estoque, folha de pagamento, contas a pagar e receber.
2.2.4 Software Científico e de Engenharia
Segundo Modesto e Oliveira (2010, p. 34), “são software que auxiliam as aplicações científicas. Têm sido caracterizados por algoritmos de processamento de números”.
2.2.5 Software Embutido ou Embargado
Para Modesto e Oliveira (2010, p. 35), são software próprios de um determinado hardware. É usado para controlar produtos e sistemas para os mercados industriais e de consumo. Tem como característica utilizar uma memória de somente leitura e usam rotinas limitadas e particulares.
2.2.6 Software de Computador Pessoal
Segundo Modesto e Oliveira (2010, p. 18), conceitua-se pelo software utilizados em computadores de uso pessoal, entre muitas outras aplicações, são responsáveis por processamento de textos, planilhas eletrônicas, computação gráfica.
2.2.7 Software de Inteligência Artificial
Conforme Modesto e Oliveira (2010, p. 18), caracteriza-se pelo uso de algoritmos não numéricos para resolver problemas complexos. Atualmente a área de AI (Artificial Intelligency) mais ativa é a dos sistemas especialistas, também chamados sistemas baseados em conhecimento.
2.2.8 Software Online
Para Modesto e Oliveira (2010, p. 18), são software que trabalham em conexão com a internet. Os arquivos não são carregados localmente e sim através de um servidor, com tempo de resposta curto, mas maior que o de tempo real.
2.3 ENGENHARIA DE SOFTWARE – CONCEITOS E ASPECTOS
Na engenharia de software há recursos aperfeiçoados e alguns não aperfeiçoados.
Abaixo uma figura conveniente que apresenta a engenharia de software em vários aspectos.
Figura 1: Engenharia de software
Fonte: CeviuBlog (2013, p. 19).
Segundo Sommerville (2004, p. 132), a engenharia de software é uma ciência da engenharia que se toma de todos os aspectos da produção de software, desde as práticas iniciais de especificação do sistema até a manutenção do mesmo, após ele entrar em operação. Com essa definição, podemos destacar dois termos importantes que são:
- estudo da engenharia: aplica as teorias, processos e ferramentas nos casos apropriados, de maneira seletiva;
- todos os aspectos da produção de software: engenharia não se designa somente aos métodos técnicos de desenvolvimento, além disso a atividade como o gerenciamento de projetos de software e o desenvolvimento de ferramentas.
Esses termos levam à busca de um processo de desenvolvimento que considere a componente “Qualidade”.
2.3.1 Paradigmas de Engenharia de Software
Conforme Seno um paradigma é escolhido tendo-se como base a natureza do projeto e da aplicação, os métodos e ferramentas a serem usados, os controles e os produtos que precisam ser entregues.
2.3.2 Modelos de Processo de Desenvolvimento de Software
Os modelos de métodos de desenvolvimento de software nasceram pela obrigação de dar resposta aos casos a avaliar, pois só na altura em que encaramos o problema é que podemos sugerir o modelo.
Nos modelos de métodos de software é oferecido um cuidado exclusivo à representação abstrata dos dados do método e sua dinâmica, não formando métodos de desenvolvimento, porque este trabalha num grau, além disso, do que os padrões de período de vida.
2.3.2.1 O Modelo em Cascata
Segundo Leite (2007, p. 20), o modelo cascata (waterfall) tornou-se conhecido na década de 70 e é referenciado na maior parte dos livros de engenharia de software ou manuais de exemplos de software. Nele as atividades do método de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima.
Conforme Leite (2007, p. 20), este modelo, introduziu enormes atributos ao desenvolvimento. A primeira chama a atenção de que o método de desenvolvimento deve ser administrado de forma disciplinada, com atividades visivelmente marcantes, apurada a partir de um plano e sujeitas a gerenciamento durante a concretização.
Outra qualidade determina de modo claro quais são estas atividades e quais as condições para cumpri-las. Finalmente, o modelo introduz o afastamento das atividades do sentido e design da atividade de programação que era o núcleo das atenções no desenvolvimento de software.
Figura 2: Modelo em cascata
Fonte: Victorino e Bräscher (2009, p. 21).
Conforme Victorino e Bräscher (2009, p. 21), o modelo em cascata é composto pelas seguintes etapas:
- levantamento de requisitos: tem por objetivo propiciar que usuários e desenvolvedores tenham a mesma compreensão do problema a ser resolvido;
- análise de requisitos: tem por objetivo construir modelos que determinam qual é o problema para o qual se procura conceber uma solução de software;
- projeto: tem por objetivo adaptar o modelo de análise de tal modo que possa servir como base para implementar a solução no ambiente alvo; - implementação: etapa em que a codificação do sistema é efetivamente
executada;
- teste: consiste na verificação do software;
- implantação: fase em que o sistema entra em produção.
2.3.2.2 Modelo Espiral
Segundo Pressman (2007, p. 65), modelo espiral é uma combinação do modelo de processo de desenvolvimento iterativo e sequencial modelo de desenvolvimento, ou seja, modelo em cascata linear com alta ênfase em análise de risco.
O modelo espiral tem quatro fases. Um projeto de software passa repetidamente por essas fases em iterações chamadas espirais.
A fase de Identificação começa com a coleta dos requisitos de negócios na espiral da linha de base. Nos espirais posteriores como o produto amadurece, a identificação de requisitos de sistema, requisitos de subsistemas e os requisitos de unidade são todas feitas nesta fase.
A fase de Projeto começa com o projeto conceitual na espiral da linha de base e envolve projeto arquitetônico, projeto lógico de módulos, design de produtos físicos e design final nas espirais subsequentes.
A fase Construir ou envergadura refere-se a produção do produto de software real em cada espiral. Na espiral da linha de base quando o produto é apenas pensado a o projeto está sendo desenvolvido e é desenvolvido nesta fase para obter feedback do cliente.
A fase de Avaliação e Análise de risco inclui identificar, estimar e monitorar viabilidade e gestão de riscos técnicos, como o não cumprimento do cronograma e superação custo. Depois de testar a acumulação, no final da primeira iteração, o cliente avalia o software e fornece o feedback.
A seguir uma representação esquemática do modelo espiral listando as atividades em cada fase:
Figura 3: Diagrama do modelo espiral
Fonte: Pressman (2007, p. 65).
Com base na avaliação do cliente, o processo de desenvolvimento de software entra na iteração seguinte e, subsequentemente, segue a abordagem linear para implementar o feedback sugerido pelo cliente. O processo de iteração ao longo da espiral continua ao longo da vida do software.
2.3.2.3 Modelo de Prototipação
Segundo Kumar (2012, p. 23), a ideia fundamental é que, em vez de congelar os requisitos antes de um projeto ou de codificação avançar, um protótipo descartável é construído para entender as requisições. Este protótipo é desenvolvido com base nos requisitos atualmente conhecidas. Ao utilizar este protótipo, o cliente pode ter uma “sensação real” do sistema, já que as interações com protótipo pode permitir que o cliente entenda melhor os requisitos do sistema desejado. Prototipagem é uma ideia atraente para sistemas complexos e grandes para as quais não há nenhum processo manual ou sistema existente para ajudar a determinar os requisitos.
Idealmente, o protótipo serve como um mecanismo para identificação dos requisitos do software. Se um protótipo executável é elaborado, o desenvolvedor tenta usar partes de programas existentes ou aplicar ferramentas (por exemplo, geradores de relatório, gestores de janelas etc.) que possibilitem programas executáveis serem gerados rapidamente (PRESSMAN, 2007, p. 67).
Conforme Kumar (2012, p. 23), devemos usar o modelo de Prototipação quando o sistema desejado precisa ter um monte de interação com os usuários finais. Normalmente os sistemas on-line, tem uma quantidade muito elevada de interação com os usuários finais, são os mais adequados para o modelo de protótipo. Pode demorar um pouco para um sistema ser construído, que permite facilidade de uso e precisa de um mínimo de treinamento para o usuário final.
2.3.2.4 O Modelo RUP
Segundo a IBM (s.d., p. 23), é um framework de processo abrangente que fornece práticas testadas pela indústria para software e sistemas de entrega e de execução, para uma gestão eficaz do projeto. É um dos muitos processos contidos na Biblioteca Processo Racional, que oferece as melhores práticas de orientação adequada para o seu desenvolvimento em particular ou necessidade do projeto.
Segundo Sommerville (2007, p. 72) as melhores práticas abordadas são as seguintes:
- desenvolver o software interativamente: planejar os incrementos de software com base nas prioridades do cliente, desenvolver e entregar o mais cedo possível às características de sistema de maior prioridade no processo de desenvolvimento;
- gerenciar requisitos: documentar explicitamente os requisitos do cliente e manter o acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças no sistema antes de aceitá-las;
- usar arquiteturas baseadas em componentes: estruturar a arquitetura do sistema com componentes, reduzindo a quantidade de software a ser desenvolvido e, consequentemente, reduzir custos e riscos;
- modelar software visualmente: usar modelos gráficos de UML para apresentar as visões estática e dinâmica do software;
- verificar a qualidade do software: garantir que o software atenda aos padrões de qualidade da organização;
- controlar as mudanças do software: gerenciar as mudanças do software, usando um sistema de gerenciamento de mudanças, procedimentos e ferramentas de gerenciamento de configuração.
Conforme Martinez (s.d., p. 24), o RUP está organizado em cinco (5) fases que são:
- fase de concepção/iniciação: esta fase abrange as tarefas de comunicação com o cliente e planejamento;
- fase de elaboração: abrange a modelagem do modelo genérico do processo;
- fase de construção: desenvolve ou adquire os componentes de software;
- fase de transição: abrange a entrega do software ao usuário e a fase de testes;
- fase de produção: a implantação é continuada e completada e ainda é feito um acompanhamento para influência das funcionalidades do software.
Figura 4: Fases do processo unificado (RUP)
Fonte: Pressman (2007, p. 73).
O modelo é melhorado por dois vetores, que são o dinâmico e o estático.
O vetor estático (eixo y), chamado de Method Content, descreve como o software é desenvolvido. Esse vetor lista as nove (9) disciplinas do RUP e abrange todo o modo como as coisas são desenvolvidas. O eixo x por sua vez captura tudo isso e distribui no tempo através de fases, iterações, atividades e subatividades, gerando processos (MORIYA, 2007).
2.4 QUALIDADE DE SOFTWARE
Conforme Campos (2013, p. 25), a ISO 9000:2005, qualidade é o grau em que um conjunto de características essenciais a um produto. Ou seja, pode-se garantir que se algum produto ou serviço atende as condições apontadas, este mesmo produto ou serviço possui a qualidade esperada.
Segundo Martins (2012, p. 25), qualidade de software é um conceito complexo, que não pode ser definido de maneira simples. Classicamente, o conhecimento de qualidade tem significado que o produto desenvolvido deve cumprir sua especificação.
Conforme Campos (2013, p. 25), a qualidade pode ter sua avaliação através do grau de satisfação que as pessoas medem um certo produto ou serviço. Esse produto ou serviço pode ter qualidade para algumas pessoas e para outras nem tanto. O termo TQM (Total Quality Management), amplamente usado nas organizações, também descreve uma abordagem para a melhoria da qualidade.
Para Kan (2002, p. 26), “O termo tem tomado vários significados, dependendo de quem interpreta e como se aplica. ” Os elementos chaves do TQM podem ser resumidos conforme a Figura 5:
Figura 5: Elementos chave do TQM
Fonte: Kan (2003, p. 26).
Segundo Campos (2013, p. 26), os elementos chave do TQM são os seguintes:
a) Foco do cliente (customer focus): tem um foco no cliente, na maioria
das vezes é um forte colaborador para o total sucesso de um negócio e envolve garantir que todos os aspectos da empresa colocam seus clientes em primeiro lugar;
b) Melhoria de processo (process improvement): é a ocupação proativa
na identificação, análise e avanço em processos de negócios existentes dentro de uma organização para otimizar e para avaliar novas quotas ou padrões de qualidade;
c) Lado humano da qualidade (human side of quality): se quiser melhorar
um sistema complexo, devemos convencer o povo em torno da empresa a fazer as coisas de forma diferente. Mas uma mudança que parece sensata e benéfica para a empresa pode sentir ameaçador para os outros;
d) Métricas, modelos, medições e análise (metrics, models, measurement and analysis): o objetivo é direcionar o progresso
contínuo em todos os parâmetros da qualidade por um sistema de avaliação orientado a metas.
2.4.1 Garantia da Qualidade do Software
Quando os modelos de negócios e os mercados mudam mais rápido do que as aplicações que os suportam pode ser desenvolvida, o teste de software é muitas vezes primeiro a ser cortado do orçamento ou cronograma, apesar do fato de que defeitos de software têm um impacto direto e negativo sobre a rentabilidade. Mesmo um pequeno número de defeitos podem ter um impacto catastrófico sobre uma empresa, seus clientes e seus parceiros. Estima-se que um defeito de software encontrado e os custos pós-produção fixa de 100 vezes mais do que se o defeito foi encontrado na fase de concepção.
Há muitos benefícios e menos riscos de ter uma organização independente
de testes de software parceiro em vez de in-house testes. Testadores
independentes e consultores de teste trazer uma imparcialidade muito necessária para os processos de teste para uma melhor qualidade, e em casa o pessoal está liberado para se concentrar em suas atividades principais. Testes independentes traz consigo as melhores of-breed de gestão da qualidade de processos, porque essa é a sua principal atividade.
2.4.2 Melhoria do Processo de Software
Conforme o IEE (Institute of Electrical and Eletronic Engineers), de forma mais comum, método é uma série de passos atingidos para uma determinada finalidade.
Segundo Sommerville (2004, p. 141), durante os últimos anos, aumentou o interesse por parte das organizações que tem desenvolvimento de software pelo avanço de suas técnicas. O avanço da metodologia significa compreender os métodos existentes e poder alterá-los. Com esse objetivo obtido, o abatimento dos valores e do período pode se tornar a fundamental meta do avanço.
Os princípios para o alcance da Melhoria de Processos de Software é fazer um levantamento das condições necessárias aos clientes, criar um ciclo de vida para os métodos e, por fim, concretizar a instalação e manutenção do próprio.
Para Silveira (2012, p. 27), para se ter uma qualidade de software depende da capacitação dos métodos. Existe investimento insuficiente das empresas em certificações que confirmem a qualidade e a maturidade dos processos na
fabricação de software. Para as pequenas empresas, esse investimento é um problema por ter um valor elevado das certificações. Com a ação de entidades privadas, centros de estudos e governo têm a probabilidade de aperfeiçoarmos os processos de software no Brasil, tendo como foco principal pequenas e médias empresas.
Segundo Sommerville (2004, p. 142), aperfeiçoar o processo de software de uma organização não é somente seguir métodos ou ferramentas exclusivas ou algum modelo de processo que tenha sido usado em diferente lugar.
... Desde que o software, como todo capital, é conhecimento incorporado, e como esse conhecimento está inicialmente disperso, tácito, latente e incompleto na sua totalidade, o desenvolvimento de software é um processo de aprendizado social. O processo é um diálogo no qual o conhecimento, que deve se transformar em software é reunido e incorporado ao software. O processo fornece interação entre usuários e projetistas, entre usuários e ferramentas em desenvolvimento e entre projetistas e ferramentas em desenvolvimento (tecnologia). É um processo iterativo no qual a própria ferramenta serve como meio de comunicação, com cada nova rodada de dialogo explicitando mais conhecimento útil do pessoal envolvido... (BAETJER, 1998, p. 85).
A elaboração de software de computador é um processo de prática, e o resultado, é a inclusão de informações coletadas, reunidos à medida que o processo é administrado. Processo é a base da engenharia de software.
Segundo Pressman (2007, p. 76), é ele que permite o desenvolvimento lógica e aceitável de softwares de computador. Processos de software compõem a base para a influência gerencial de projetos de software e constitui o conteúdo no qual os métodos técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios, formulários, etc.) são produzidos, os limites são constituídos, a qualidade é garantida e as alterações são adequadamente administradas.
Assim como os produtos, os processos também têm atributos ou características (Tabela 1).
Tabela 1: Características do processo Característica do Processo Descrição Facilidade de compreensão
Até que ponto o processo está explicitamente definido e com que facilidade se pode compreender a definição do processo?
Visibilidade As atividades de processo culminam em resultados nítidos, de modo que o progresso do processo seja externamente visível?
Facilidade de suporte
Até que ponto as atividades do processo podem ser apoiadas por ferramentas CASE? Aceitabilidade O processo definido é aceitável e utilizável pelos engenheiros responsáveis pela produção
do produto de software?
Confiabilidade O processo está projetado de tal maneira que seus erros sejam evitados ou identificados antes que resultem em erros no produto?
Robustez O processo pode continuar, mesmo que surjam problemas inesperados? Facilidade de
manutenção
O processo pode evoluir para refletir os requisitos mutáveis da organização ou melhorias de processo identificadas?
Rapidez Com que rapidez pode ser concluído o processo de entrega de um sistema, a partir de uma determinada especificação?
Fonte: Sommerville (2004, p. 145).
É por meio do avanço nos processos de software que se visa chegar a um acréscimo de qualidade e a uma obra final que atenda o mercado em geral porque ela envolve distintos aspectos, dentre eles temos os técnicos, os gerenciais e até mesmo, os culturais:
- disposição das obras de avanço ao assunto;
- dispor uma tática e colocar quais os objetivos de interesse da organização;
- opção de um exemplo de processo para ter como referência, por exemplo, CMM, ISO/IEC 15504 (SPICE e CMMI);
- opção de um processo para o avanço de produtos (por exemplo, IDEAL e Guia 15504);
- informação da situação atual das práticas da organização; - idealização;
- implantação de atos de avanço;
- acompanhamento, avaliação e institucionalização do avanço.
2.5 MODELO DE QUALIDADE DE SOFTWARE
Desenvolver software de qualidade assegurada, com elevada produtividade, dentro do prazo estabelecido e sem necessitar de mais recursos que os alocados, tem sido o grande desafio da Engenharia de Software.
2.5.1 Modelo CMMI
Segundo Pressman (2007, p. 691), o CMMI (Capability Maturity Model Integration) é uma abordagem para a melhoria de processos compatível com a Norma ISSO 15504 (SPICE). Embora as duas abordagens sejam semelhantes, o CMMI não foi baseado em SPICE, como se poderia pensar. O modelo foi constituído de forma independente, com participação da indústria, do governo norte-americano e do Instituto de Engenharia de Software (SEI) da Carnegie Mellon University (CMU). CMMI é o sucessor do modelo CMM (Capability Maturity Model), que foi desenvolvido entre 1987 e 1997. Em 2002 foi lançada a versão 1.1 do CMMI, e, em novembro de 2010, a versão 1.3.
A versão atual do CMMI possui três vertentes:
a) CMMI para aquisição (CMMI-ACQ): provê diretrizes para suporte às
decisões relacionadas à aquisição de produtos e serviços;
b) CMMI para desenvolvimento (CMMI-DEV): provê diretrizes para
monitorar, mensurar e gerenciar processos de desenvolvimento;
c) CMMI para serviços (CMMI-SVC): provê diretrizes para entrega de
serviços dentro das organizações e para clientes externos.
Os modelos CMMI podem ser usados como guias para desenvolver e melhorar processos da organização, e também como um framework para avaliar a maturidade dos processos da organização.
CMMI se originou na indústria de software, mas também tem sido adaptado a outras áreas, como a indústria de hardware, serviços e comércio em geral. O termo “software” sequer aparece nas definições de CMMI, o que torna o modelo bem mais abrangente do que seu predecessor, o CMM.
Existem duas representações do CMMI, a representação contínua e a representação em estágios. A representação contínua é projetada para permitir à empresa focar em processos específicos que deseja melhorar em função de suas prioridades. Já a representação em estágios é aplicada à organização como um todo e permite que se compare a maturidade de diferentes organizações.
Os principais componentes da estrutura do CMMI estão representados na Figura 6 e definidos a seguir:
Figura 6: Componentes da estrutura do CMMI-DEV
Fonte: SEI (2010b, p. 36).
2.5.2 Modelo ISO/IEC 9126
Conforme Pressman (2007, p. 362) o ISO/IEC 9126 trata da avaliação do produto de software, do ponto de vista das suas características de qualidade. A norma é aplicável para quem faz aquisição e/ou de desenvolvimento de software, usuários, assim como para quem fornece suporte, manutenção ou realiza auditoria de software.
Esta norma não é aplicada com o objetivo de obter uma certificação através de um esquema de reconhecimento mútuo. A norma sugere sua aplicação nas seguintes situações:
- definir os requisitos de qualidade do software;
- avaliar especificações de software para verificar se satisfazem os requisitos de qualidade durante o desenvolvimento;
- descrever características e atributos do software implementado; - avaliar o software desenvolvido antes de ser entregue;
- avaliar o software antes da aceitação.
Segundo Pressman (2007, p. 363) a norma sugere a avaliação dos atributos da qualidade do software relacionados a Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e Portabilidade.
Funcionalidade: um conjunto de atributos que satisfazem necessidades
Os subconjuntos de requisitos de qualidade funcionais são: - adequabilidade; - exatidão; - interoperabilidade; - conformidade; - segurança.
Confiabilidade: um conjunto de atributos relacionados à capacidade do
software de manter seu nível de desempenho, conforme as condições estabelecidas por um período de tempo estabelecido.
Subconjuntos de requisitos de qualidade de confiabilidade são: - maturidade;
- tolerância a falhas;
- capacidade de recuperação.
Usabilidade: um conjunto de atributos relacionados ao esforço para usar o
software ou na avaliação individual de tal uso, por um ou mais usuários. Subconjuntos de requisitos de qualidade de usabilidade são: - facilidade de entendimento;
- facilidade de aprendizagem; - facilidade de operação.
Eficiência: um conjunto de atributos que dizem respeito à relação entre o
nível de desempenho do software e à quantidade de recursos usada, sob condições estabelecidas.
Subconjuntos de requisitos de qualidade de eficiência são: - comportamento do tempo;
- comportamento de recursos.
Facilidade de manutenção: um conjunto de atributos relacionados ao
esforço necessário para realizar modificações específicas.
Subconjuntos de requisitos de qualidade de facilidade de manutenção são: - facilidade de análise;
- facilidade de mudança; - estabilidade;
- facilidade de teste.
Portabilidade: um conjunto de atributos de software relacionados à
Subconjuntos de requisitos de qualidade de portabilidade são: - capacidade de adaptação; - facilidade de instalação; - nível de conformidade; - facilidade de substituição. 2.5.3 Modelo MPS
Conforme o Guia de Avaliação (2009, p. 6), busca-se que o modelo MPS seja apropriado ao perfil de empresas com tamanhos desiguais e qualidades, privadas e públicas, apesar de que com específico cuidado às micro, pequenas e médias empresas. Também se acredita que o modelo MPS seja compatível com os padrões de qualidade aceitos internacionalmente e que traga como pressuposto a aplicação de toda a capacidade existente nos modelos de avanço de processo já disponíveis. Ele apresenta como base os requisitos de processos definidos nos exemplos de avanço de processo e recebe a obrigação de inserir os princípios de engenharia de software de forma acertada ao assunto das empresas, ficando em acordo com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software.
3 PROJETO MPS.BR
O programa MPS.BR é uma iniciativa brasileira para melhoria contínua de processos de software criado em dezembro de 2003. O MPS.BR tem como uma de suas metas definir e aperfeiçoar um modelo de avanço e avaliação de processo de software, focando preferencialmente as micro, pequenas e médias empresas, de forma a atender suas necessidades de negócios e ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software.
A Softex – Associação para Promoção da Excelência do software Brasileiro, é responsável pela coordenação do Programa MPS.BR e conta com o apoio do Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Internacional de Desenvolvimento (BID).
Segundo Guia Geral de Software (2012, p. 13) o MPS.BR é constituído dos seguintes componentes: Modelo de Referência (MR-MPS); Método de Avaliação (MA-MPS); e Modelo de Negócio (MN-MPS). O MR-MPS tem como base técnica as normas ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 20000 e o modelo CMMI-DEV. O MA-MPS tem como base técnica a norma ISO/IEC 15504. Cada um é constituído de guias e documentos que permitem a implementação/avaliação dos projetos de melhoria de processos.
A Figura 7 apresenta o Programa MPS.BR e seus componentes:
Figura 7: Componentes do programa MPS.BR
Conforme o Guia Geral de Software (2012, p. 14), a finalidade do projeto MPS.BR é o melhoramento de processos do software brasileiro, para alcançar suas metas a médio e longo prazo temos:
a) uma meta técnica, que tende essencialmente a concepção e aperfeiçoamento do modelo MPS;
b) qualquer meta de negócio, apontando à dispersão e adoção do modelo MPS, em todas as regiões, em um período de tempo justo.
3.1 BASE TÉCNICA PARA A DEFINIÇÃO DOS COMPONENTES DO MPS.BR
Diversos modelos de processos de desenvolvimento de software surgiram nos últimos anos como, por exemplo, os apresentados pelos padrões ISO/IEC 12207, ISO/IEC 15504 e ISO/IEC 20000.
3.1.1 ISO/IEC 12207:2008
A Norma ISO/IEC 12207 foi criada pela ISO – The International Organization for Standardization e o IEC - International Electrotechnical Commission dentro de um esforço conjunto dessas organizações.
Conforme Rocha, Maldonado e Weber (2001, p. 12), ISO/IEC 12207 – Esse padrão internacional ou modelo de referência chamado de Processo do Ciclo de Vida do Software e tem como objetivo fundamental fornecer uma estrutura excepcional para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidos com o desenvolvimento de software usem uma linguagem comum que é constituída na forma de processos bem marcantes.
Em 1988, deu início ao desenvolvimento da norma e em agosto de 1995 ela foi divulgada como norma internacional. Em 1998, foi divulgada a sua versão brasileira que tem o nome igual a internacional, apenas acrescentada as iniciais NBR.
Conforme Lima (2013, p. 42), a ISO/IEC 12207 estabelece 5 processos fundamentais, 8 processos de apoio, 4 processos organizacionais e um processo de adaptação, totalizando 18 processos, conforme apresentado na Figura 8.
Figura 8: Processos do ciclo de vida de software
Fonte: Rocha, Maldonado e Weber (2001, p. 13).
Segundo Bischoff (2008, p. 63) os 18 processos da ISO/IEC 12207 estão arranjados em 4 classes de processos com o objetivo específico, conforme a lista a seguir:
I. Classe dos processos fundamentais: são os processos constituídos pelas atividades essenciais de início e execução para o desenvolvimento, operação e a manutenção no ciclo de vida do software. Os processos fundamentais definidos na norma são:
- processo de aquisição: atividade do adquirente; - processo de fornecimento: atividade do fornecedor; - processo de operação: atividade do operador; - processo de manutenção: atividade do mantenedor.
II. Classe dos processos de apoio: são os processos constituídos por atividades que auxiliam processos fundamentais ou organizacionais. Essa classe é composta pelos processos de documentação, gerência de configuração, garantia de qualidade, verificação, validação, revisão conjunta e resolução de problemas.
III. Classe dos processos organizacionais: esses processos são formados pelas atividades para estabelecer e implementar uma estrutura constituída dos processos do ciclo de vida e pessoal envolvido no desenvolvimento do software. Nessa classe são definidos os processos de gerência, infraestrutura, melhoria e treinamentos.
IV. Classe do processo de adaptação: atividades elementares para adaptar a norma de forma a viabilizar a sua aplicação na organização ou em projetos, como
por exemplo: estratégia de aquisição, ciclo de vida de projetos, cultura organizacional, técnicas de desenvolvimento, características de produtos e serviços de software.
É possível também que nem todas as etapas do ciclo de vida ocorram para um determinado software. Exemplo disso é quando se pretende adquirir um programa já pronto, o que exclui a fase de desenvolvimento.
3.1.2 ISO/IEC 15504
Segundo Anacleto et al. (2003, p. 2), o modelo de referência ISO/IEC 15504 também conhecido como SPICE, foi desenvolvido como um framework para ter uma avaliação de processos de engenharia de software e do arranjo do projeto e do negócio. É organizado e classificado como as melhores técnicas em duas extensões que são: nível de capacidade e categoria de processos. Ultimamente a norma é comum podendo ser usada por diferentes tipos de processos, não estando mais excepcionalmente dedicada a software. Apesar disso, sua principal finalidade é o avanço e a avaliação dos processos, nos dois casos três elementos fundamentais devem ser exatamente definidos para que a avaliação de processos seja alcançada conforme a ISO/IEC 15504, sendo:
1. os processos: devem ser verificados por um avaliador competente, segundo os requisitos previstos na norma;
2. uma escala de medida: deve ter como referência um modelo de avaliação de processos compatível;
3. um método de medição: deve ser realizado seguindo um processo compatível.
Com novas opiniões a ISO/IEC 15504 foi disponibilizado um padrão de referência de processo PRM (Process Reference Model). Este padrão criou uma arquitetura como padrão de referência de método com duas dimensões: Dimensões de Processo e Dimensão da Capacidade do Processo.
Dimensão de processo
Conforme Maciel, Valls e Savoine (s.d., p. 5), é constituído por cinco categorias avaliadas como essenciais para uma adequada prática da engenharia de software. As categorias da dimensão de processos são:
- CON – consumidor e fornecedor: tem um impacto direto sobre os consumidores;
- ENG – engenharia: esta categoria agrupa os processos que levam à implementação do produto;
- SUP – suporte: seus processos dão suporte e apoio aos demais processos da organização;
- MAN – administração: na categoria de gerência estão incluídos os processos que de forma genérica podem ser usados na administração de todo outro processo ou do projeto em si;
- ORG – organização: inclui todos os processos organizacionais da empresa como infraestrutura.
A dimensão de capacidade permite uma avaliação mais detalhada dos processos executados por uma organização. Enquanto a dimensão de processo se limita à verificação de execução ou não dos processos, a dimensão de capacidade leva a uma avaliação de níveis semelhantes aos do CMMI (KOSCIANSKI; SOARES, 2007, p. 177).
A ISO/IEC 15504 também define seis níveis de capacidade que são mostradas na Tabela 2.
Tabela 2: Níveis da ISO/IEC 15504
NÍVEL NOME DESCRIÇÃO
0 Incompleto O processo não é implementado ou falha em atingir seus objetivos.
1 Executado O processo essencialmente atinge os objetivos, mesmo se de forma planejada ou rigorosa.
2 Gerenciado
O processo é implementado de forma controlada (planejado, monitorado e ajustado); os produtos por ele criados são controlados e mantidos de forma apropriada.
3 Estabelecido O processo é implementado de forma sistemática e consistente. 4 Previsível
O processo é executado e existe um controle que permite verificar se ele se encontra dentro dos limites estabelecidos para atingir os resultados.
5 Otimizado O processo é adaptado continuamente para, de uma forma mais eficiente, atingir os objetivos de negócio definidos e projetados. Fonte: Koscianski e Soares (2007, p. 178).
Cada um doa níveis apresentados possui incluídos os atributos de processo que são aplicáveis a todos os processos.
O modelo de referência ISO/IEC 15504 é compatível com CMMI (Capability Maturity Model Integration).
3.1.3 ISO/IEC 20000
Segundo Guia Geral de Software (2012, p.16), a norma ISO/IEC 20000 [ISO/IEC, 2011] publicada em dezembro de 2005 tem como finalidade fornecer um padrão de referência comum para uma empresa proporcionar serviços de TI para clientes internos ou externos. Esta norma fornece a adoção de um enfoque de processos associada para a gestão de serviços de TI e alinha-se com os melhores métodos do ITIL para entrega e suporte de serviços. A ISO/IEC 20000 incide em cinco elementos, sob o título geral Tecnologia da Informação – Gerenciamento de Serviços.
Segundo o Guia Geral de Software (2012, p.16), a ISO/IEC 20000-1 aponta ao provedor de serviços as condições para projetar, estabelecer, implementar, atuar, monitorar, revisar, sustentar e aperfeiçoar o GSTI (Gerenciamento de Serviços de TI). As condições contêm o projeto, mudança, entrega e avanço dos serviços para acatar as condições antecipadamente acordados. A ISO/IEC 20000-2 concebe um acordo do setor sobre padrões de qualidade em processos de GSTI e apresenta as melhores práticas para esses processos [ISO/IEC, 2011]. A ISO/IEC TR 20000-3 abastece orientações, explicações e indicações para a definição do escopo, aplicabilidade e demonstração da conformidade com a ISO/IEC 20000-1 pelo uso de exemplos práticos. A ISO/IEC 20000-4 tem como finalidade facilitar o desenvolvimento de um modelo para avaliação de processo de acordo com a norma ISO/IEC 15504. O modelo de referência de processo, previsto nesta norma, é um perfil lógico dos dados dos processos para o gerenciamento de serviços que podem ser aplicados em um nível básico. Todo processo é descrito em termos de uma finalidade e resultados associados. A ISO/IEC 20000-5 expõe um exemplo de plano de prática no qual são fornecidos guias para os provedores de serviços acatarem aos requisitos da ISO/IEC 20000-1.
3.1.4 MPS.BR e suas Estruturas de Apoio
O programa MPS.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM). Por meio destas estruturas, o MPS.BR obtém a participação de representantes de universidades, instituições governamentais, centros de pesquisa e de organizações privadas, os quais contribuem com suas visões complementares que agregam qualidade ao empreendimento.
Cabe ao FCC:
- emitir parecer que subsidie decisão da SOFTEX sobre o credenciamento de Instituições Implementadoras (II) e Instituições Avaliadoras (IA);
- monitorar os resultados das Instituições Implementadoras (II) e Instituições Avaliadoras (IA), emitindo parecer propondo à SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS.
Cabe à ETM apoiar a SOFTEX sobre os aspectos técnicos relacionados ao Modelo de Referência (MR-MPS) e Método de Avaliação (MA-MPS), para:
- criação e aprimoramento contínuo do MR-MPS, MA-MPS e seus guias específicos;
- capacitação de pessoas por meio de cursos, provas e workshops.
3.2 DESCRIÇÃO DOS MODELOS MPS
O MPS.Br conta com um modelo de referência, o MR-MPS e também com um método de avaliação, que é o MA-MPS, além de ter um modelo de negócio que é o MN-MPS, o segundo foi criado porque existem empresas que terão de fazer a análise e avaliação de como as empresas que estão fazendo parte do MPS.Br estão agindo.
3.2.1 Descrição do Modelo de Referência MR-MPS
Segundo o Guia Geral de Software (2012, p. 17), o Modelo de Referência MPS (MR-MPS) determina níveis de maturidade que é um ajuste entre processos e sua capacidade.
Conforme o Guia Geral de Software (2012, p. 17), o significado dos processos segue a forma exposta no modelo de referência ISO/IEC 15504-2, afirmando a intenção e os resultados esperados de sua execução. Isso admite avaliar e atribuir graus de efetividade no cumprimento dos processos. As atividades e serviços necessários para atender ao propósito e aos resultados aguardados não são determinadas mas sim carecem ficar a cargo dos usuários do MR-MPS.
Capacidade do processo é a diferenciação da habilidade do processo para conseguir os objetivos de negócios, atuais e futuros; permanecendo relacionada com o acolhimento das características de processos associados aos processos de cada nível de maturidade.
3.2.2 Descrição do Modelo de Avaliação MA-MPS
Segundo o Guia Geral de Software (2012, p. 18), é composto basicamente pelos requisitos do método, atividade do método, indicadores para avaliação e características da qualificação dos avaliadores. Este método permite a realização de avaliação em unidades organizacionais segundo o modelo MPS.
O processo de avaliação é composto por quatro fases: Preparação e planejamento, condução da avaliação, Resultados e certificação.
3.2.3 Descrição do Modelo de Negócio MN-MPS
Segundo o Guia Geral de Software (2009, p. 45), o modelo MPS estabelece um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software.
O modelo de negócio contém descrição de regras de negócios para implementação do MR-MPS pelas instituições implementadoras, avaliação seguindo o MA-MPS pelas instituições avaliadoras.
4 PROCESSO MPS.BR
Segundo o Guia Geral de Software (2012, p. 18), os processos no MPS-BR são descritos em termos de propósito e resultados. O propósito descreve o objetivo geral a ser atingido durante a execução do processo.
Os resultados esperados do processo constituem os resultados a serem alcançados com a efetiva prática do processo. Estes resultados podem ser confirmados por um produto de trabalho determinado ou uma alteração expressiva de estado ao se executar o processo.
4.1 CAPACIDADE DO PROCESSO
Segundo o Guia Geral de Software (2012, p. 18), a capacidade do processo é representada por um conjunto de atributos de processo descrito em termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional. No MR-MPS-SW, à medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido.
Os diferentes níveis de capacidade dos processos são descritos por nove atributos de processos (AP) descritos a seguir:
- AP 1.1 – o processo é executado: este atributo confirma o quanto o processo chega ao seu propósito;
- AP 2.1 – o processo é gerenciado: este atributo confirma o quanto a execução do processo é gerenciada;
- AP 2.2 – os produtos de trabalho do processo são gerenciados: este atributo confirma o quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente;
- AP 3.1 – o processo é definido: este atributo confirma o quanto um processo padrão é sustentado para apoiar a prática do processo definido; - AP 3.2 – o processo está implementado: este atributo confirma o quanto o
processo padrão é efetivamente praticado como um processo definido para chegar aos seus resultados;
- AP 4.1 – o processo é medido: este atributo confirma o quanto os resultados de avaliação são usados para certificar que a execução do processo alcance os seus objetivos de performance e apoia o alcance dos objetivos de negócio definidos;
- AP 4.2 – o processo é controlado: este atributo confirma o quanto o processo é controlado estatisticamente para produzir um processo durável, capaz e previsível dentro dos limites constituídos;
- AP 5.1 – o processo é objeto de melhorias incrementais e inovações: este atributo confirma o quanto as alterações no processo são identificadas a partir do exame de defeitos, problemas, causas comuns de alteração do desempenho e da busca de aspectos inovadores para a definição e prática do processo;
- AP 5.2 – o processo é otimizado continuamente: este atributo confirma como as alterações na definição, gerência e desempenho do processo têm impacto essencial para a obtenção dos objetivos acentuados do avanço do processo.
4.1.1 Atributos de Processo
Segundo o Guia Geral de Software (2012, p. 24), os atributos do processo são nove (9) e são eles que descrevem o nível de capacidade do processo. O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Esses níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Em outras palavras, na passagem para um nível de maturidade superior, os processos anteriormente implementados devem passar a ser executados no nível de capacidade exigido neste nível superior.
Na Tabela 3 são descritos os níveis de maturidade, os processos de cada um deles e também os atributos apropriados.
Tabela 3: Níveis de maturidade do MR-MPS
Fonte: Guia Geral de Software (2012, p. 24).
4.1.2 Exclusão de Processos
Conforme Guia Geral de Software (2012, p. 24), determinados processos podem ser excluídos, absoluta ou parcialmente, do escopo de uma avaliação MPS por não serem pertinentes ao negócio da unidade organizacional que está sendo avaliada. Toda exclusão necessita ser justificada no Plano de Avaliação. O consentimento das exclusões e suas justificativas é de responsabilidade do Avaliador Líder.
4.2 NÍVEIS DE MATURIDADE
Os níveis de maturidade colocam patamares de desenvolvimento de processos, distinguindo estágios de avanço da implementação de processos na
organização. O nível de maturidade em que se encontra uma organização aceita prever a sua performance no futuro ao executar um ou mais processos.
Segundo Guia Geral de Software (2012, p. 26), o MR-MPS-SW determina sete níveis de maturidade: G (Gerenciado Parcialmente), F (Gerenciado), E (Definido Parcialmente), D (Definido Largamente), C (Definido), B (Gerenciado Quantitativamente) e A (Otimização). A escala de maturidade tem início no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que recomendam onde a organização necessita colocar o empenho do progresso. A melhoria e a obtenção de um determinado nível de maturidade do MR-MPS-SW se obtêm porque são atendidas as finalidades e todos os resultados esperados dos respectivos processos e os resultados esperados das características de processo constituídos para aquele nível.
A separação em 7 estágios tem a finalidade de permitir uma prática e avaliação apropriada às micros, pequenas e médias empresas. A possibilidade de se realizar avaliações considerando mais níveis ainda permite uma visibilidade dos resultados de avanço de processos em tempos mais curtos.
4.2.1 Nível G – Parcialmente Gerenciado
O nível de maturidade G é composto pelos processos Gerência de Projetos e Gerência de Requisitos. Neste nível a implementação dos processos deve satisfazer os atributos de processo AP 1.1 e AP 2.1.
GERÊNCIA DE PROJETOS - GPR
O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. O propósito deste processo evolui à medida que a organização cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são incorporados, de forma que a gerência de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados. No nível B, a gerência de projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da organização. Novamente, alguns resultados evoluem e outros são incorporados.
