DETEC – DEPARTAMENTO DE TECNOLOGIA
ALINE MARIA MENEGOL KRONBAUER
PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS
DE SOFTWARE BRASILEIRO (MPS.BR) EM INSTITUIÇÕES DO TIPO
FÁBRICA DE SOFTWARE.
Ijuí 2010
ALINE MARIA MENEGOL KRONBAUER
PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS
DE SOFTWARE BRASILEIRO (MPS.BR) ) EM INSTITUIÇÕES DO
TIPO FÁBRICA DE SOFTWARE.
Trabalho de Conclusão de Curso para a obtenção do título de Bacharel em Sistemas de Informação pela Universidade Regional do Noroeste do Estado do Rio Grande do Sul.
Coordenador: Msc. Marcos Ronaldo Cavalheiro Orientador: Ms. Romário Lopes Alcântara
Ijuí 2010
ALINE MARIA MENEGOL KRONBAUER
PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS
DE SOFTWARE BRASILEIRO (MPS.BR) ) EM INSTITUIÇÕES DO
TIPO FÁBRICA DE SOFTWARE.
Trabalho de Conclusão de Curso para a obtenção do título de Bacharel em Sistemas de Informação pela Universidade Regional do Noroeste do Estado do Rio Grande do Sul.
Banca Examinadora:
________________________________________________ Prof. MSc. Romário Lopes Alcântara
________________________________________________ Prof. MSc. Marcos R. M. Cavalheiro
AGRADECIMENTOS
Agradeço a ajuda de meu orientador, Romário, pelo carinho, pela cobrança e principalmente pela paciência com que sempre me auxiliou;
Agradeço a meus professores que sempre souberam sanar minhas dúvidas e me dedicaram seu tempo para as explicações extras;
Agradeço a meus colegas pelo apoio, estímulo e amizade.
“Seu tempo é limitado, então não percam tempo vivendo a vida de outro. Não sejam aprisionados pelo dogma – que é viver com os resultados do pensamento de outras pessoas. Não deixe o barulho da opinião dos outros abafar sua voz interior. E mais importante, tenha a coragem de seguir seu coração e sua intuição. Eles de alguma forma já sabem o que você realmente quer se tornar. Tudo o mais é secundário.”
LISTA DE FIGURAS.
Figura 1: Evolução Tecnológica do Software ... 19
Figura 2: Sobre a Engenharia de Software ... 20
Figura 3: Modelo por Prototipação ... 23
Figura 4: Modelo em Espiral... 24
Figura 5: Fases do Processo Unificado ... 26
Figura 6: Qualidade Interna e Externa ISO/IEC 9126: NBR 13596 ... 31
Figura 7: Componentes. ... 37
Figura 8: Gerenciamento de Custos do Projeto ... 63
LISTA DE TABELAS.
TABELA 1: Leis da Evolução de Software de Lehman ... 18
TABELA 2: Níveis de Maturidade do MR-MPS ... 43
TABELA 3: MPS e CMMI ... 67
TABELA 4: Custo em R$ da Implementação e Avaliação do Projeto de Melhoria de
LISTA DE SIBLAS E ABREVIATURAS.
AP: Atributo de Processo
CMMI: Capability Maturity Model Integration
EAP: Estrutura Analítica de Projeto
ETM: Equipe Técnica do Modelo
FCC: Fórum de Credenciamento e Controle
FINEP: Financiadora de Estudos e Projetos
IA: Instituição Avaliadora
IEC: International Electrotechnical Commission
II: Instituição Implementadora
IOGE: Instituição Organizadora de Grupo de Empresas
ISO: International Organization for Standardization
MA-MPS: Método de Avaliação para Melhoria de Processo de Software
MN-MPS: Modelo de Negócio para Melhoria de Processo de Software
MPS.BR: Melhoria de Processo do Software Brasileiro
MR-MPS: Modelo de Referência para Melhoria de Processo de Software
PMBOK: Guia do Conjunto de Conhecimentos em Gerenciamento de
Projetos
PU: Processo Unificado
RAP: Resultado do Atributo de Processo
RUP: Rational Unified Process
SOFTEX: Associação para Promoção da Excelência do Software Brasileiro
TI: Tecnologia da Informação
SUMÁRIO.
RESUMO... 12
INTRODUÇÃO ... 13
1. UM POUCO SOBRE SOFTWARE ... 15
1.1. Aplicações de Software ... 16
1.1.1. Software de Sistemas... 16
1.1.2. Software de Tempo Real ... 16
1.1.3. Software Comercial ... 16
1.1.4. Software Científico ... 17
1.1.5. Software Embutido ... 17
1.1.6. Software de Computador Pessoal ... 17
1.1.7. Software de Inteligência Artificial ... 17
1.2. Evolução do Software ... 18
2. ENGENHARIA DE SOFTWARE – CONCEITOS E ASPECTOS ... 20
2.1. Paradigmas da Engenharia de Software ... 21
2.1.1. Principais Paradigmas da Engenharia de Software ... 21
2.1.1.1. O Modelo em Cascata ... 22
2.1.1.2. O Modelo Prototipação ... 22
2.1.1.3. O Modelo em Espiral ... 23
2.1.1.4. O Modelo RUP ... 25
3. QUALIDADE DE SOFTWARE ... 27
3.1. Melhoria da Qualidade de Software ... 28
3.2. Alguns Modelos de Qualidade de Software... 29
3.2.1. O Modelo CMMI ... 29 3.2.2. O Modelo ISO 9126 ... 31 3.2.3. O Modelo MPS ... 32 4. PROJETO MPS.BR ... 33 4.1. Normas Envolvidas ... 34 4.2. Estruturas de Apoio ... 36 4.3. Descrição do Modelo MPS ... 36
4.3.1. O Modelo de Referência ... 38
4.3.2. O Método de Avaliação ... 39
4.3.3. O Modelo de Negócio ... 40
4.3.4. Níveis de Maturidade... 41
4.3.4.1. Nível G – Parcialmente Gerenciado ... 44
4.3.4.2. Nível F – Gerenciado ... 45
4.3.4.3. Nível E – Parcialmente Definido ... 46
4.3.4.4. Nível D – Largamente Definido ... 47
4.3.4.5. Nível C – Definido ... 47
4.3.4.6. Nível B – Gerenciado Quantitativamente ... 48
4.3.4.7. Nível A – Em Otimização ... 48
5. PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS DE SOFTWARE BRASILEIRO (MPS.BR) EM INSTITUIÇÕES DO TIPO FÁBRICA DE SOFTWARE. ... 49
5.1. Análise da Situação Atual ... 50
5.1.1. Aspectos Referentes à Empresa ... 51
5.1.2. Os Profissionais e suas Características ... 52
5.1.2.1. Conscientização e Treinamento ... 53
5.2. Análise dos Processos da Empresa ... 54
5.3. Gerenciamento de Processos ... 54
5.3.1. Resultados Esperados para o Gerenciamento de Processos Abordados pelo Nível G ... 56
5.4. Gerenciamento de Requisitos ... 60
5.4.1. Levantamento de Requisitos ... 61
5.4.2. Resultados Esperados para o Gerenciamento de Requisitos Abordados pelo Nível G. ... 62
5.5. Custos ... 63
5.6. Comprometimento e Controle ... 65
5.7. Benefícios ... 65
5.8. Comparativos ... 67
5.8.1. Comparativo em Relação aos Custos ... 68
CONSIDERAÇÕES FINAIS ... 70
REFERÊNCIAS BIBLIOGRÁFICAS ... 72
ANEXO A: Exemplo de aplicação de um modelo de placar para avaliação de
projetos (Viabilidade) ... 75
RESUMO.
O setor tecnológico está sendo utilizado cada vez mais em uma ampla variedade de áreas de aplicação, freqüentemente produzindo sistemas de informações maiores e mais complexos. Em função de participar amplamente no cotidiano das pessoas e organizações, as atividades de produção e controle da qualidade de software tornam-se vitais para a difusão e permanência desta tecnologia no mercado. Neste contexto, a abordagem aqui proposta visa fornecer um meio de visualização genérica da qualidade de software inserida nas organizações, além de resgatar previamente um pouco do ciclo de evolução dos softwares e de aspectos da história da engenharia desse produto. A melhoria de processos de software se torna indispensável para as organizações frente à tamanha concorrência. Pensando nisso é que, nesta pesquisa, far-se-á um estudo detalhado de como se dá o processo do projeto MPS.Br (Melhoria de Processos de Software Brasileiro), quais as etapas existentes, qual a importância desse projeto e, por último como se dá a implementação do Nível G de aplicação do Projeto MPS.Br em empresas do tipo fábrica de software.
Palavras-chave: Software - Engenharia de Software - Qualidade de Software – MPS.Br.
INTRODUÇÃO.
O mundo real está em constante mudança, e sistemas são feitos para refletir comportamentos do mundo real (Gall, 1997). Isto nos remete a questão de que, além de somente evoluir, o software deve acompanhar a evolução do usuário e de seus interesses, bem como da organização, e, a questão da padronização é importante para estabelecer um norte a ser seguido.
O projeto MPS.Br surgiu em dezembro de 2003 com o objetivo de ser uma alternativa para micro, pequenas e médias empresas em relação a melhoria de processos de software.
Esta pesquisa tem como meta iniciar uma abordagem teórica na área de melhoria de processos de software, expor os métodos usados e a estrutura do projeto MPS.Br (Melhoria de Processos de Software Brasileiro). Também é objetivo desta pesquisa, a conscientização das empresas de que devem fazer parte de processos de melhoria de software, alertar as organizações e profissionais para a padronização e chamar a atenção para o crescimento da indústria de software de qualidade em nosso país.
Portanto, o trabalho a seguir, contará com um histórico da evolução e também aspectos referentes à Engenharia de Software, trazendo conceitos e abordando alguns paradigmas e modelos de processos de software. Este, também contará com uma breve explanação dos conceitos de qualidade e melhoria de software, passando por questões de padronização e abordando alguns modelos existentes.
Posteriormente, contará com uma demonstração da estrutura do projeto MPS.Br, de seus componentes e de como é feito o acompanhamento de projetos de melhoria de software. O Modelo de Referência será um pouco melhor detalhado, pois este é a base para toda a aplicabilidade das melhorias, observando que o
mesmo contém a explanação de quais os requisitos necessários para se iniciar com a implementação do projeto.
A fase mais específica fica por conta da abordagem da implementação do Nível G ou Nível Parcialmente Gerenciado do Modelo MPS.Br, trazendo aspectos pertinentes a esse nível de maturidade e sugestões de como planejar a implementação e dar continuidade às tarefas propostas no cronograma e planejamento do projeto de desenvolvimento de softwares.
Esta pesquisa possibilita uma visão global e genérica de como implementar o primeiro nível do Modelo MPS, iniciando pela análise de aspectos e processos já praticados no dia-a-dia organizacional, passando pelo planejamento de ações, custo e tempo de projeto levando em consideração o que a empresa já tem instituído em seu dia-a-dia e o que pode mudar a partir da aplicação do nível G de maturidade.
Todos esses aspectos serão devidamente ponderados ao longo deste estudo, trazendo soluções para melhor atender aos Guias propostos pelo Modelo MPS e comparações entre o modelo proposto e o CMMI e ainda explanando os possíveis benefícios que o Projeto MPS.Br poderá trazer ao meio organizacional e ao que se propõe o nível de maturidade G ou Parcialmente Gerenciado do Projeto de Melhoria de Processos de Software Brasileiro.
1. UM POUCO SOBRE SOFTWARE
O Software é um mecanismo que torna possível o aproveitamento e a vazão do potencial da microeletrônica. É um produto que evoluiu de uma ferramenta de análise de informações e de resolução de problemas especializados para uma grande indústria da programação.
Ninguém na década de 1950 poderia ter previsto que o software fosse se tornar uma tecnologia indispensável para negócios, ciência e engenharia; que o software fosse permitir a criação de novas tecnologias (por exemplo, engenharia genética), a extensão de tecnologias existentes (por exemplo, telecomunicações), e o declínio de antigas tecnologias (por exemplo, a indústria tipográfica); que o software se tornaria a força motriz por trás da revolução do computador pessoal; que produtos de software em pequenas embalagens seriam comprados pelos consumidores em centros comerciais da vizinhança; que uma empresa de software fosse se tornar maior e mais influente que a maioria das empresas da era industrial; que uma vasta rede guiada por softwares, chamada internet, evoluiria e modificaria tudo, desde a pesquisa em bibliotecas até a maneira de os consumidores comprarem e, até mesmo, os hábitos de marcas encontro dos adultos jovens (e não tão jovens). (PRESSMANN, 2008)
O produto de software não é feito através de um processo mecânico, mas sim projetado e desenvolvido por engenharia. Geralmente são criados por meio de um conjunto de convenções que mapeiam as exigências dos clientes para só então transformá-las em um código executável em máquina, ou seja, a linguagem de programação.
O que chama a atenção para o software e o que fez com que esse produto fosse tão difundido foi a variedade ilimitada de usos a que se dispõe, além da alta velocidade e da incrível capacidade de armazenamento de informações.
1.1. Aplicações de software
1.1.1. Software de sistemas
Segundo Pressmann (2008) é uma coleção de programas escritos para servir a outros programas. Tem a característica de manter uma relação de interação com o hardware bastante acentuada, múltiplos usuários, operações concorrentes, recursos compartilhados, gestão de processos, estruturas de dados complexas e múltiplas interfaces externas. Como exemplo Pressman cita compiladores, editores, acionadores, softwares de rede, entre outros.
1.1.2. Software de tempo real
Um sistema de tempo real é um sistema cujo funcionamento correto depende dos resultados produzidos por ele e do tempo em que esses resultados são produzidos. (NOGUEIRA, 2010). Não esquecendo que um sistema de tempo real deve responder dentro de um determinado tempo pré-estipulado.
1.1.3. Software comercial
É o software desenvolvido por uma empresa com o objetivo de lucrar com sua utilização. (WIKIPEDIA, 2010)
Geralmente esse tipo específico de software é usado nas operações comerciais e nas tomadas de decisões administrativas.
1.1.4. Software científico
Esses são sistemas que tem como característica o processamento de números.
1.1.5. Software embutido
Reside dentro de um produto ou sistema e é usado para implementar e controlar características e funções para o usuário final e para o próprio sistemas. O software embutido pode realizar funções muito limitadas e particulares (por exemplo, o controle de teclado para um forno de micro-ondas) ou fornecer função significativa e capacidade de controle (por exemplo, funções digitais em um automóvel tais como controle de combustível, mostradores do painel e sistemas de frenagem etc.). (PRESSMANN, 2008)
1.1.6. Software de computador pessoal
Para Pressmann (2008), são os softwares que entraram em efervescência na última década, tais como processamento de textos, planilhas eletrônicas, computação gráfica, diversões, gerenciamento de dados, aplicações financeiras pessoais e comerciais, redes externas ou acesso a banco de dados, são apenas algumas das centenas de aplicações.
1.1.7. Software de inteligência artificial
O software para inteligência artificial faz uso de algoritmos não-numéricos para resolver problemas complexos que não são passíveis de computação
ou análise direta. Aplicações nessa área incluem robótica, sistemas especialistas, reconhecimento de padrões (de imagem e de voz), redes neurais artificiais, prova de teoremas e jogos. (PRESSMAN, 2008)
1.2. Evolução do Software
Indubitavelmente, a tecnologia de software está sendo utilizada cada vez mais em uma ampla variedade de áreas de aplicação. Desta forma, seu correto funcionamento torna-se essencial para o sucesso do negócio envolvido e para a segurança do ser humano (ISO, 2005).
O termo evolução reflete um processo de mudança progressivo nos atributos ou características da entidade que está evoluindo. (LEHMAN e RAMIL, 2002)
Uma entidade ou uma coleção de entidades podem ser ditas a evoluir, se o seu valor ou capacidade se altera ao longo do tempo. Isto significa que individualmente ou coletivamente, as entidades se vão adaptando em função de um ambiente em mudança. (FONTE, Nelson Baptista, 2010)
Lehman (2002) cita os softwares do tipo E que são programas ou sistemas de software que ajudam a resolver um problema ou realizam atividades do mundo real. Estes tipos de sistemas são propícios a mudança e atualização, logo, a uma evolução.
A Tabela 1 traz elencadas as leis de evolução de softwares do tipo E criadas por Lehman (2002).
TABELA 1: Leis da Evolução de Software de Lehman.
Nº / ANO NOME LEI
I (1974) Mudança Contínua
Um sistema do tipo E tem de ser continuadamente adaptado, caso contrário, tornar-se-á progressivamente menos satisfatório de usar.
II (1974) Aumento da Complexidade
Caso um sistema do tipo E evolua, a sua complexidade tende a aumentar, a não ser que exista trabalho com o intuito de manter ou reduzir a complexidade atual.
III (1974) Auto-regulação Todos os processos evolutivos dos sistemas do tipo E são auto-regulados.
IV (1978)
Conservação da estabilidade organizacional
O ritmo da atividade média nos processos do tipo E, tende a se manter constante durante a vida operacional do sistema ou fases dessa vida.
V (1978) Conservação da familiaridade
Em geral, a média do crescimento incremental dos sistemas do tipo E tende a diminuir.
VI (1991) Crescimento Contínuo
A capacidade funcional dos sistemas do tipo E tem de ser aumentada continuamente, para manter a satisfação do utilizador durante a vida útil do sistema.
VII (1996) Declínio da Qualidade
Embora sejam tomadas rigorosas medidas que visam a adaptação perante a mudança, a qualidade dos sistemas de tipo E tende a diminuir conforme vai evoluindo.
VIII (1996)
Sistemas de Resposta (reconhecida em 1971, formulada em 1996)
Processos evolutivos do tipo E são sistemas de respostas multi-nível, multi-ciclo e multi-agente.
Fonte: (LEHMAN, 2002).
A Figura 1 traz um breve histórico do software nos últimos anos.
Figura 1: Evolução Tecnológica do Software
2. ENGENHARIA DE SOFTWARE – CONCEITOS E ASPECTOS
Na engenharia de software há soluções melhores e soluções piores, não há soluções certas e soluções erradas, não há medidas objetivas de sucesso. (Ian Sommerville, 2006, apud Anders Lyhne Christensen, 2009/2010, apud Manuel Menezes de Sequeira, 2009/2010).
Abaixo uma gravura interessante que mostra a engenharia de software em vários aspectos, abordando o assunto do ponto de vista de diversos cargos ocupados por profissionais da área.
Figura 2: Sobre a Engenharia de Software
Fonte: (WORDPRESS.COM, 2008).
A Figura 2 objetiva mostrar, de uma forma humorística, a falta de comunicação, de normas e de padronização dentre as diferentes etapas existentes na elaboração de um produto. Interpretando o que é mostrado, pode-se perceber a falta ou a má aplicação da engenharia, trazendo gastos desnecessários e projetos insatisfatórios.
A engenharia de software visa englobar todos os aspectos a cerca da produção de software, tem como objetivo principal e fundamental a construção de sistemas que serão usados por outras pessoas e empresas em seu cotidiano e que esses sistemas sejam extremamente confiáveis e manuteníveis.
2.1. Paradigmas da Engenharia de Software
São estratégias definidas e utilizadas para o desenvolvimento de software, abrangem métodos, ferramentas e procedimentos.
Funcionam com um tipo de roteiro para nortear desenvolvedores no sentido de padronização e organização de software.
2.1.1. Principais Paradigmas da Engenharia de Software
No dicionário da língua portuguesa, paradigma significa modelo, padrão, protótipo. Conjunto de unidades suscetíveis de aparecerem num mesmo contexto, sendo, portanto, comutáveis e mutuamente exclusivas. No paradigma, as unidades têm, pelo menos, um traço em comum (a forma, o valor ou ambos) que as relaciona, formando conjuntos abertos ou fechados, segundo a natureza das unidades.
Pode-se dizer que paradigma de engenharia de software é um modelo padrão a ser seguido para o desenvolvimento do software em si. Este modelo deve ser de certa forma, escolhido, levando em consideração os aspectos positivos e negativos e a realidade do produto a ser criado.
2.1.1.1. O Modelo em Cascata
Também chamado de clico de vida clássico, prega um desenvolvimento linear e seqüencial. O projeto passa por etapas, na quais só poderá passar para a próxima fase quando a anterior tiver sido totalmente concluída, não é permitido retornar e é justamente esse o seu ponto fraco, pois dessa forma não permite a revisão no processo e conseqüente alteração.
A vantagem do desenvolvimento cascata é que ele permite controle departamental e gerencial. Um planejamento pode ser atribuído com prazo final para cada estágio de desenvolvimento e um produto pode prosseguir no processo de desenvolvimento, teoricamente ser entregue no prazo. O desenvolvimento move do conceito, através do projeto (design), implementação, teste, instalação, descoberta de defeitos e termina com a operação e manutenção. Cada fase de desenvolvimento prossegue em uma ordem estrita, sem qualquer sobreposição ou passos iterativos. (PRESSMAN, 2006)
2.1.1.2. O Modelo por Prototipação
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, 2006)
O modelo de prototipagem inicia a partir de uma solicitação de proposta enviada pelo cliente aos desenvolvedores do software e é construído em período curto de tempo com a explanação de todos os requisitos para que os mesmos sejam examinados e questões pertinentes sejam esclarecidas. Os clientes podem fazer experimentações com o modelo e decidir se satisfaz as suas necessidades ou se serão necessárias alterações.
FIGURA 3: Modelo por Prototipação
Fonte: (PRASS, S/D)
A Figura três (3) ilustra o modelo por prototipação, o cliente é o primeiro a ser questionado e ouvido, somente após as suas sugestões e exigências o modelo passa para a fase de desenho e construção e para finalizar a etapa, o cliente faz a avaliação do modelo proposto e pode optar por aprovar o projeto ou então por realizar modificações.
Pressman (2006) também afirma que:
Apesar de a prototipagem poder ser usada como um modelo de processo independente, ela é mais comumente usada como uma técnica que pode ser implementada dentro do contexto de qualquer um dos modelos de processo existentes. Independentemente da maneira como é aplicado, o paradigma de prototipagem auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos.
2.1.1.3. O Modelo em Espiral
De certa forma é uma seleção de características do modelo por prototipação e também do modelo em cascata, com o acréscimo de um elemento: a análise de riscos.
Segundo Pressman (2006), usando o modelo espiral, o software é desenvolvido numa série de versões evolucionárias. Durante as primeiras iterações,
as versões podem ser um modelo de papel ou protótipo. Durante as últimas iterações, são produzidas versões cada vez mais completas do sistema submetido à engenharia.
FIGURA 4: Modelo em Espiral
FONTE: (BOEHM, S/D)
A Figura 4 traz o modelo em espiral através da ótica de Boehm (S/D). A primeira etapa é a comunicação com o cliente, o levantamento de requisitos com o mesmo, suas sugestões e exigências. A fase seguinte é a de planejamento do projeto em si e a terceira etapa aborda o levantamento e análise de riscos. A engenharia, ou seja, a estrutura do projeto é feita na etapa quatro (4). A avaliação do cliente é a penúltima etapa e, após tudo ter sido devidamente aprovado, passa-se para a fase final onde é realizada a construção e entrega do mesmo. Ao mesmo tempo em que as etapas vão sendo alcançadas, Boehm emprega que cada uma delas apresenta uma divisão de processos, que seriam o desenvolvimento dos conceitos, desenvolvimento do novo produto, melhora do produto e, manutenção do produto.
2.1.1.4. O Modelo RUP.
De certo modo, o processo unificado (PU) é uma tentativa de apoiar-se nos melhores recursos e características dos modelos convencionais de processo de software, mas caracterizá-los de um modo que implemente muitos dos melhores princípios de desenvolvimento ágil de softwares. (PRESSMAN, 2006).
O processo unificado racional, ou simplesmente modelo RUP é considerado incremental, pois versões vão sendo criadas e nelas, feitas melhorias e iterativo, é um modelo orientado a objetos e que adequado à UML.
O RUP prega que o processo seja adaptável, que haja um balanceamento nas prioridades dos interessados, que o grau de colaboração entre as equipes seja elevado e que haja agregação continuada de valor entre outros princípios chaves. (MORIYA, 2007).
O modelo é formado 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 sub-atividades, gerando processos. (MORIYA, 2007)
As fases do modelo RUP são cinco (5). A fase inicial é a de concepção do projeto, nela a interação com o cliente é fundamental, pois é feito o levantamento de requisitos e o planejamento do projeto com um todo. Depois do planejamento vem a fase de elaboração onde a comunicação com o cliente continua e se inicia a modelagem. Na fase de construção, os componentes de software são desenvolvidos e finalizados. A próxima fase é a de transição onde são dados os ajustes finais e se inicia a implantação do software, também é nessa fase que são feitas as avaliações por parte dos usuários. A última fase do modelo RUP é a produção, a implantação é continuada e finalizada e também é feito um acompanhamento para controle das funcionalidades do software. Essas cinco (5) fases estão ilustradas na Figura 5.
FIGURA 5: Fases do Processo Unificado.
FONTE: (PRESSMAN, 2006)
É provável que, ao mesmo tempo em que as fases de construção, transição e produção estejam sendo conduzidas, o trabalho já tenha sido iniciado no incremento de software seguinte. Isso significa que as cinco fases do Processo Unificado não ocorrem em sequência, mas em titubeante concorrência. (PRESSMANN, 2006)
3. QUALIDADE DE SOFTWARE
SOMMERVILLE (2004), diz que:
Processo de software é um conjunto de atividades e resultados associados que levam à produção de um produto de software. Esse processo pode envolver o desenvolvimento de software desde o início, embora, cada vez mais, ocorra o caso de um software novo ser desenvolvido mediante a expansão e a modificação de sistemas já existentes.
Qualidade é fator crítico de sucesso para a indústria de software. Para que se tenha um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando à oferta de produtos de software e serviços correlatos conforme padrões internacionais de qualidade. (GUIA DE AVALIAÇÃO, 2009)
Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. (GUIA GERAL, 2009.
A engenharia de software, entre outros assuntos priva pelo desenvolvimento de produtos de software de qualidade. A qualidade de software é uma área de conhecimento da engenharia de software que objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente. (WIKIPEDIA, 2010)
A aplicação de qualidade de software surgiu devido a vários aspectos relacionados à organização, planejamento e padronização em seu desenvolvimento.
A tarefa de elaborar um sistema eficiente ficava antes somente por conta dos desenvolvedores, que a faziam de acordo com seus princípios de organização, entretanto, com a rotatividade de profissionais, isso causava danos as organizações pois a manutenção dos sistemas se tornava demasiadamente complexa uma vez que um programador pensa totalmente diferente de outro.
A conseqüência desse turbilhão de problemas foi a criação e desenvolvimento de padrões voltados para a melhoria da qualidade para os produtos de software.
3.1. Melhoria da Qualidade de Software
A melhoria da qualidade de software pode ser dividida em melhoria de qualidade de processo de software e melhoria de qualidade de produto de software. As normas para qualidade de produto de software possuem características que um produto com qualidade deve ter, modo de medir essas características de qualidade e descrições para se fazer a avaliação do produto.
As normas para obtenção de qualidade de processo de software fazem um estudo dos requisitos necessários ao cliente, criam um ciclo de vida para os processos e, por final, realizam a instalação e manutenção do mesmo.
É através da melhoria nos processos de software que se visa chegar a um desenvolvimento de qualidade e a um produto final que satisfaça o mercado em geral, pois ela envolve diferentes aspectos, dentre eles temos os técnicos, os gerenciais e até mesmo, os culturais:
I) Alinhamento das ações de melhoria ao contexto;
II) Montar uma estratégia e estabelecer quais os objetivos de negócio da organização;
III) Escolha de um modelo de processo para ter como referência, por exemplo, CMM, ISO/IEC 15504 (SPICE e CMMI);
IV) Escolha de um método para a melhoria de produtos (por exemplo, IDEAL e Guia 15504);
V) Conhecimento do estado atual das práticas da organização;
VI) Planejamento;
VII) Implantação de ações de melhoria;
VIII) Acompanhamento, medição e institucionalização da melhoria.
Além desses aspectos, ainda existe a definição, utilização e melhoria contínua dos processos envolvidos na aquisição, fornecimento, desenvolvimento, operação, manutenção e suporte de sistemas de software.
3.2. Alguns Modelos de Qualidade de Software
3.2.1. O MODELO CMMI
O CMMI é um modelo reconhecido internacionalmente e considerado muito importante na padronização de regras que unem várias disciplinas para atingir um conjunto de melhores práticas de programação. Porém, existem problemas de custo nesse modelo, pois ele se torna inviável para empresas de pequeno e médio porte.
O modelo SW-CMM® (Software Capability Maturity Model) foi definido pelo SEI (Software Engineering Institute) a pedido do Departamento de Defesa dos Estados Unidos. A partir de 1991, foram desenvolvidos CMMs para várias disciplinas (Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gerência e Desenvolvimento da Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto). Embora estes modelos tenham mostrado sua utilidade, o uso de múltiplos modelos se mostrou problemático. O CMMI® surgiu para resolver o problema de utilização de vários modelos e é o resultado da evolução do SW-CMM®, SECM® (System Engineering Capability Model) e IPD-CMM® (Integrated
Product Development Capability Maturity Model). É, portanto, o sucessor destes modelos. Além disso, o framework CMMISM foi desenvolvido para ser consistente e compatível com a ISO/IEC 15504. Em 2006 foi publicada a versão 1.2 do CMMI®, o CMMI-DEV® (CMMI for Development).
O modelo CMMI foi baseado e tem seus objetivos voltados para a qualidade total e também prioriza o amadurecimento gradativo do processo de desenvolvimento de softwares dentro das organizações. Ele possui 5 (cinco) níveis de maturidade. Organizações que alcançarem o nível inicial do CMMI, ou seja o nível 1, estão aptos a obter softwares de alta qualidade, mas isto depende do desempenho dos desenvolvedores da equipe.
Para alcançar o nível 2 (dois), as organizações devem acompanhar e documentar os métodos voltados ao gerenciamento de vários aspectos do desenvolvimento de software para assegurar o cumprimento de prazos e custos.
O nível 3 (três) trata da documentação, integração e padronização dos processos padrão para as organizações, todos os projetos terão de usar uma versão aprovada e adaptada para o seu desenvolvimento e manutenção.
As avaliações do software são tratadas no nível 4 (quatro), o processo e o produto de software são avaliados e, a partir daí, o gerente pode tomar decisões a cerca de como atuar no próprio processo.
No último nível, a questão tratada é a continuidade na melhoria dos processos.
À medida que uma organização cresce em termos de maturidade, ela institucionaliza seu processo de desenvolvimento de software através de políticas, normas e estruturas organizacionais, as quais geram uma infra-estrutura e uma cultura de suporte aos métodos e procedimentos de desenvolvimento.
3.2.2. O MODELO ISO 9126
Esta norma foi publicada em 1991, contendo características que definem um produto de qualidade. A ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, que se enquadra no modelo de qualidade das normas da família 9000. Em 1996 foi lançada a norma brasileira correspondente, a NBR 13596.
Após a publicação, foram lançadas diversas revisões e melhorias e foram então criadas divisões para esta norma:
I) ISO/IEC 9126-1: Modelo de Qualidade;
II)ISO/IEC 9126-2: Métricas Externas;
III)ISO/IEC 9126-3: Métricas Internas;
IV)ISO/IEC 9126-4: Métricas de Qualidade em Uso.
A norma ISO/IEC 9126 está focada principalmente na qualidade de software e propõe atributos para o mesmo.
FIGURA 6: Qualidade interna e externa ISO/IEC 9126: NBR13596
Fonte: (WIKIPEDIA, 2010)
A Figura 5 demonstra os seis (6) atributos pertencentes a qualidade interna e externa de software e também as suas sub-características.
3.2.3. O MODELO MPS
Busca-se que o modelo MPS seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Também se espera que o modelo MPS seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princípios de engenharia de software de forma adequada ao contexto das empresas, estando em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software. (GUIA DE AVALIAÇÃO, 2009)
4. Projeto MPS.BR
Surgiu em dezembro de 2003 através de uma parceria entre a Softex (Associação para Promoção da Excelência do Software Brasileiro), Governo representado pelo Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de Desenvolvimento (BID), além de contar com o apoio de universidades. As entidades citadas entraram em acordo e iniciaram o desenvolvimento de um projeto que beneficiasse empresas de todos os portes uma vez que as normas ISO/IEC (regulamentam a produção de softwares) se tornam inviáveis para algumas empresas de micro, pequeno e médio porte por serem demasiadamente onerosos os gastos para alcançar este tipo de certificação.
Segundo o Guia Geral (2009), o objetivo do projeto MPS.Br é a Melhoria de Processo do Software Brasileiro, com duas metas a alcançar a médio e longo prazos:
I) Uma meta técnica, que visa basicamente a criação e aprimoramento do modelo MPS. Essa primeira meta, conta com os seguintes resultados: guias do modelo MPS; Instituições Implementadoras credenciadas que terão a incumbência de prestar serviços de consultoria para a implementação do modelo de referência; Instituições Avaliadoras credenciadas que deverão prestar serviços de avaliação seguindo o método de avaliação MA-MPS; Consultores de Aquisição certificados para posteriores serviços de consultoria de aquisição de software e serviços relacionados;
II) Uma meta de mercado, visando à disseminação e adoção do modelo MPS, em todas as regiões do país, em um intervalo de tempo justo, a um custo razoável, tanto em PME (foco principal) quanto em grandes organizações públicas e privadas, com resultados esperados tais como: criação e aprimoramento do modelo de negócio MN-MPS; cursos, provas e workshops; organizações que implementaram o modelo MPS; organizações com avaliação MPS publicada (prazo de validade de três anos).
Portanto nota-se que o objetivo do projeto não é inovar, mas sim, tornar o que já existe compatível com a realidade das empresas brasileiras.
4.1. Normas envolvidas
Existe uma base técnica para a construção e aprimoramento do modelo de melhoria e avaliação de processo de software, essa base é composta pelas normas:
I) ISO/IEC 12207:2008 [ISO/IEC, 2008a]: Processos do Ciclo de Vida do Software. Foi criada pela ISO – International Organization for Standardization e o IEC - International Electrotechnical Commission. Em 1988, foi proposto o desenvolvimento da norma e em agosto de 1995 ela foi publicada como Norma Internacional. Em 1998, foi publicada a sua versão brasileira que tem o mesmo nome que a internacional, somente acrescida das iniciais NBR. Em outubro de 2002 e 2004, foram feitas atualizações na Norma Internacional ISO/IEC 12207, chamadas de emendas 1 e 2 respectivamente, onde foram inseridas melhorias que criaram novos ou expandiram o escopo de alguns processos, inseriram para cada processo o seu propósito e resultados e para os novos processos definiram suas atividades e tarefas. Essas modificações tiveram o objetivo de representar a evolução da Engenharia de Software, as necessidades vivenciadas pelos usuários da norma e a harmonização com a série ISO/IEC 15504. Em 2008, a Norma Internacional ISO/IEC 12207 foi reformulada, incorporando as melhorias que já apareciam nas emendas 1 e 2 e harmonizando sua estrutura à Norma Internacional ISO/IEC 15288. A norma ISO/IEC 12207:2008 foi publicada também como padrão IEEE (IEEE Std 12207:2008) e estabelece uma arquitetura comum para o ciclo de vida de processos de software com uma terminologia bem definida. Contém processos, atividades e tarefas a serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação, manutenção e descarte de produtos de software, bem como partes de software de um sistema. A norma também
se aplica à aquisição de sistemas, produtos de software e serviços relacionados à área.
II) ISO/IEC 15504-2 [ISO/IEC, 2003]: Avaliação de Processo. Em setembro de 1992, a ISO realizou um estudo chamado “Necessidades e Exigências para uma Norma de Avaliação de Processos de Software”. O trabalho concluiu que era pertinente a elaboração de uma norma que fosse aplicável à melhoria de processos e à determinação da capacidade. Este padrão deveria considerar os métodos e normas já existentes (como por exemplo, o SW-CMM® e a ISO 9001), abranger todos os processos de software e ser construído pelos especialistas que já desenvolviam e trabalhavam com os métodos e normas existentes à época. Como resultado desse primeiro trabalho, a ISO iniciou em janeiro de 1993 o projeto SPICE (Software Process Improvement and Capability dEtermination) com o objetivo de produzir inicialmente um relatório técnico que fosse, ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específico que a norma ISO 9001 originando, assim, a série de normas ISO/IEC 15504: Parte 1 [ISO/IEC, 2004a], Parte 2 [ISO/IEC, 2003], Parte 3 [ISO/IEC, 2004b], Parte 4 [ISO/IEC, 2004c] e Parte 5 [ISO/IEC, 2006]. Posteriormente, em 2008, mais duas partes foram desenvolvidas: Parte 6 [ISO/IEC, 2008b] e Parte 7[ISO/IEC, 2008c]. A ISO/IEC 15504 presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional. Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar uma avaliação com o objetivo de gerar um perfil dos processos que será usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de decisão de contratá-lo ou não.
4.2. Estruturas de Apoio
FCC (Fórum de Credenciamento e Controle) que tem como função a emissão de pareceres que subsidiem decisão da SOFTEX sobre o credenciamento de Instituições Implementadoras e Instituições Avaliadoras; monitorar os resultados das Instituições Implementadoras e Instituições Avaliadoras, emitindo pareceres propondo à SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS.
A ETM (Equipe Técnica do Modelo) segundo o Guia Geral (2009), é a equipe técnica responsável pela definição e aprimoramento do MR-MPS, MA-MPS e guias específicos. Tem a função de apoiar a SOFTEX sobre os aspectos técnicos relacionados ao Modelo de Referência e Método de Avaliação, para a criação e aprimoramento contínuo dos dois modelos citados e de seus guias, além de ter como responsabilidade a capacitação de pessoas por meio de cursos, provas e workshops.
Ainda falando sobre a ETM, é de função dela também, a elaboração de guias que falem e especifiquem como deve ser feita a aquisição, a implementação e a avaliação dos softwares, bem como do Guia Geral do Modelo MPS.Br.
Por meio das estruturas citadas acima, 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. (GUIA GERAL, 2009)
4.3. Descrição do Modelo 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
analise e avaliação de como as empresas que estão fazendo parte do MPS.Br estão agindo, ou seja, o projeto não está voltado somente para a produção de bons softwares, mas sim pela continuidade do projeto e de como as empresas que entrarem no projeto continuarão a fazer parte do mesmo entre outros aspectos. Essa estrutura de modelos foi criada para que a melhoria de produtos de software seja estabelecida e a padronização garantida.
Cada um destes componentes é apresentado e especificado em guias que juntos formam a documentação do modelo MPS.
FIGURA 7: Componentes.
Fonte: (GUIA GERAL, 2009).
Na Figura 6, observa-se uma demonstração dos modelos ISO, CMMI e MPS. Nela estão elencados todos os métodos e modelos que participam do desenvolvimento dos projetos. Observa-se ainda que alguns modelos pertencem a mais de um projeto, como é o caso do modelo de referência que tanto é parte do CMMI, do ISO e também do modelo MPS.
I) Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação;
II) Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as
instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS. (SOFTEX, 2009)
III) Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA). (SOFTEX, 2009).
IV) Guia de Implementação: série de dez documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS. (SOFTEX, 2009)
4.3.1. Modelo de Referência
Para que determinada organização esteja em conformidade com o modelo MPS a mesma deve alcançar determinados requisitos, é o modelo de referência o responsável por especificar esses requisitos básicos. Através de uma combinação entre processos e suas respectivas capacidades, o MR-MPS define níveis de maturidade para o software.
Segundo o Guia Geral (2009), nível de maturidade é o grau de melhoria de processo para um predeterminado conjunto de processos no qual todos os resultados esperados do processo e dos atributos dos processos são atendidos.
Os níveis de maturidade demonstram a evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização, ou seja, o nível de maturidade serve como um termômetro que mede como está se dando a evolução da organização. Tendo consciência de qual o nível no qual se encontra determinada organização, é possível prever o seu desempenho futuro ao executar um ou mais processos. Existem sete níveis de maturidade estabelecidos pelo MR-MPS. Esta escala de maturidade se inicia 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 indicam onde a organização deve colocar o esforço de melhoria.
O alcance de um determinado nível e o avanço para outro, se obtêm quando são atendidos os propósitos estabelecidos para determinado nível. Os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo também devem ser alcançados para só então dar por concluído o nível em questão.
4.3.2. Método de Avaliação
O modelo de avaliação basicamente consiste em definir uma instituição avaliadora e verificar a maturidade com que a organização está conduzindo a execução dos processos. O método de avaliação tem início a partir do momento em que o patrocinador da avaliação define uma instituição que será a avaliadora. O encerramento do modelo de avaliação se dá no momento em que os dados produzidos e analisados são registrados em uma base de dados confidencial da SOFTEX.
O patrocinador da avaliação pode ser alguém da gerência da organização que está implementando o modelo, ou também pode ser alguém da entidade que esteja propondo a avaliação. O comprometimento do patrocinador é essencial para assegurar que os objetivos da avaliação sejam atingidos.
A atitude da gerência da unidade organizacional tem forte impacto nos resultados de uma avaliação. O responsável pela unidade organizacional deve motivar os participantes de forma aberta e construtiva. Deve, também, deixar claro a todos que a avaliação tem como foco principal, o processo em si, e não o desempenho dos indivíduos que participam do processo.
O fornecimento de feedback e o estabelecimento de uma atmosfera que encoraje a discussão aberta sobre os resultados preliminares, durante a avaliação, ajudam a assegurar que a avaliação seja significativa para a unidade organizacional.
O respeito à confidencialidade das fontes de informação e documentação recolhidas durante a avaliação é essencial para que se obtenham informações consistentes.
É de suma importância que os colaboradores e servidores da organização se sintam em uma atmosfera agradável e que tenham a percepção de que a avaliação resultará em benefícios que os ajudarão direta ou indiretamente a realizar o seu trabalho. É importante que todas as partes confiem que os avaliadores têm a experiência necessária para realizar a avaliação, são imparciais e têm um entendimento adequado da unidade organizacional.
A avaliação depois de concluída tem validade de três (3) anos a contar da data da avaliação final feita na organização, ou seja, não é vitalícia.
O processo de avaliação é composto por quatro (4) subprocessos que iniciam com a contratação da avaliação, em sequência a preparação da realização da avaliação, após a realização da avaliação final e por último, a documentação dos resultados da avaliação.
Resultam do método de avaliação a obtenção de dados e informações que caracterizam os processos de software da organização, a determinação do grau em que os resultados esperados são alcançados e os processos atingem o seu propósito e por fim a atribuição de um nível de maturidade do MR-MPS à organização.
4.3.3. Modelo de Negócio
O modelo MPS estabelece um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software. (GUIA GERAL, 2009)
O modelo de negócio contém descrição de regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras, avaliação seguindo o MA-MPS pelas Instituições Avaliadoras, organização de grupos de empresas pelas
Instituições Organizadoras de Grupos de Empresas (IOGE) para implementação do MR-MPS e avaliação MA-MPS, certificação de Consultores de Aquisição (CA) e programas anuais de treinamento do MPS.BR por meio de cursos, provas e workshops.
4.3.4. Níveis de Maturidade
O modelo MPS baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos. (GUIA GERAL, 2009)
A maturidade em processos de software é quem define os meios pelos quais o software é definido, gerenciado, medido, controlado e efetivo, isto implica na evolução das capacidades dos processos. Em uma empresa com o grau de maturidade elevado, o desenvolvimento de software é muito bem entendido por toda a equipe técnica, isto se dá graças à existência da documentação adequada e de políticas de treinamento de pessoal continuadas.
Na passagem para um nível de maturidade superior, os processos anteriormente implementados no nível anterior, passam a ser executados no nível de capacidade atual.
Algumas denominações presentes no modelo MPS e que contribuem para o avanço dos níveis de maturidade pela instituição devem ser conhecidos:
I) Processo: deve ser proposto e deve principalmente, se destinar
aquilo que se propõe, não fugindo de seus objetivos. O propósito descreve o objetivo geral a ser atingido durante a execução do processo. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo. Estes resultados podem ser evidenciados por um produto de trabalho produzido ou uma mudança significativa de estado ao se executar o processo.
II) Capacidade do processo: expressa o grau de refinamento e
institucionalização com que o processo é executado na organização/unidade organizacional. À 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. (GUIA GERAL, 2009). A capacidade do processo avalia os resultados obtidos e identifica com que grau de refinamento e institucionalização o processo foi executado na organização. A partir daí é que vai ser definido em qual grau de maturidade a empresa se encontra e se pode evoluir. A 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.
III) Atributos do processo: segundo o GUIA GERAL (2009), 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). Isto significa que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. 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.
IV) Resultados Esperados por Processo: No MPS.BR cada processo
tem um propósito e seus resultados esperados. Resultado esperado do processo é resultado observável do sucesso do alcance do propósito do processo. (ISO, 2002)
Na tabela 2, estão descritos os níveis de maturidade, os processos de cada um deles e ainda os atributos correspondentes.
TABELA 2: Níveis de maturidade do MR-MPS.
Nível Processos Atributos de Processo
A
AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2 , AP 5.1 e AP 5.2
B Gerência de Projetos – GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2, AP 4.1 e AP 4.2
C
Gerência de Riscos – GRI
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Desenvolvimento para Reutilização – DRU Gerência de Decisões – GDE
D
Verificação – VER
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Validação – VAL
Projeto e Construção do Produto – PCP Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
E
Gerência de Projetos – GPR (evolução)
AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
Gerência de Reutilização – GRU
Gerência de Recursos Humanos – GRH Definição do Processo Organizacional – DFP Avaliação e Melhoria do Processo Organizacional – AMP
F
Medição – MED
AP 1.1, AP 2.1 e AP 2.2 Garantia da Qualidade – GQA
Gerência de Portfólio de Projetos – GPP Gerência de Configuração – GCO Aquisição – AQU
G Gerência de Requisitos – GRE AP 1.1 e AP 2.1 Gerência de Projetos – GPR
Fonte: Guia Geral – MPS.BR (SOFTEX, 2009)
Atributo de processo é uma característica mensurável da capacidade do processo aplicável a qualquer processo [ISO/IEC 15504-1, 2004]. Quando determinado atributo de processo for atingido, uma avaliação é realizada com base nos resultados alcançados.
4.3.4.1. Nível de Maturidade G ou Parcialmente Gerenciado.
O nível de maturidade G ou parcialmente gerenciado, é composto pelos processos gerência de projetos e gerência de requisitos.
I) Gerência de Projetos (GPR): esse processo tem como propósito fundamental estabelecer e manter planos que definam 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. Este propósito evolui à medida que a organização avança os níveis de 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.
II) Gerência de Requisitos (GRE): é o responsável por gerenciar os requisitos do produto e dos componentes de projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.
Dois pontos são desafiadores na implantação do nível G. O primeiro ponto se refere à mudança de cultura organizacional, orientando a definição e melhoria dos processos de desenvolvimento de software e o segundo aspecto é pertinente à definição do conceito acerca do que é “projeto” para a organização.
4.3.4.2. Nível F – Gerenciado.
Fazem parte deste nível de maturidade os processos de aquisição (AQU), gerência de configuração (GCO), garantia da qualidade (GQA), gerência de portfólio de projetos (GPP) e o processo de medição (MED).
I) Aquisição (AQU): é responsável por gerenciar a aquisição de produtos que satisfaçam às necessidades exigidas pelo cliente.
II) Gerência de Configuração (GCO): tem como objetivo estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos.
III) Garantia da Qualidade (GQA): tem como propósito fundamental, assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos.
IV) Gerência de Portfólio de Projetos (GPP): inicia e mantém projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização. Este processo compromete o investimento e os recursos organizacionais adequados e estabelece a autoridade necessária para executar os projetos selecionados. Ele executa a qualificação contínua de projetos para confirmar que eles justificam a continuidade dos investimentos, ou podem ser redirecionados para justificar.
V) Medição (MED): tem como propósito coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais.
4.3.4.3. Nível E – Parcialmente Definido.
Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G e F), acrescidos dos processos avaliação e melhoria do processo organizacional, definição do processo organizacional, gerência de recursos humanos e gerência de reutilização. O processo gerência de projetos sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com base no processo definido para o projeto e nos planos integrados.
Fazem parte do nível de maturidade E, quatro (4) processos: o processo de avaliação e melhoria do processo organizacional (AMP), o processo gerência de recursos humanos (GRH), o processo organizacional (DFP) e o processo de reutilização (GRU).
I) Avaliação e Melhoria do Processo Organizacional (AMP): têm como propósito determinar o quanto os processos padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização a planejar, realizar e implantar melhorias contínuas nos processos com base no entendimento de seus pontos fortes e fracos.
II) Gerência de Recursos Humanos (GRH): tem a responsabilidade de prover a organização e os projetos com os recursos humanos necessários e manter suas competências adequadas às necessidades do negócio.
III) Definição do Processo Organizacional (DFP): tem como propósito estabelecer e manter um conjunto de ativos de processo organizacional e padrões do ambiente de trabalhos usáveis e aplicáveis às necessidades de negócio da organização.
IV) Reutilização (GRU): tem como propósito fundamental o gerenciamento do ciclo de vida dos ativos reutilizáveis.
4.3.4.4. Nível D – Largamente Definido.
O nível de maturidade D é composto pelos processos dos níveis de maturidade anteriores (G ao E), acrescidos dos processos desenvolvimento de requisitos, integração do produto, projeto e construção do produto, validação, e verificação.
I) Desenvolvimento de Requisitos (DRE): define os requisitos do cliente, do produto e também dos componentes do produto.
II) Integração do Produto (ITP): tem como propósito elencar os componentes do produto, objetivando a produção integrada e consistente com o projeto.
III) Projeto e Construção do Produto (PCP): o objetivo deste processo é a projeção, desenvolvimento e implementação de soluções para atender aos requisitos impostos pelo planejamento.
IV) Validação (VAL): o propósito desse processo é verificar e confirmar que o produto final está apto para o mercado e que atenderá ao objetivo a que se propõe.
V) Verificação (VER): é o responsável por confirmar que cada serviço ou produto atende apropriadamente os requisitos exigidos no planejamento.
4.3.4.5. Nível C – Definido.
O nível de maturidade C é composto pelos processos dos níveis de maturidade anteriores (G ao D), acrescidos dos processos desenvolvimento para reutilização, gerência de decisões e gerência de riscos.
I) Desenvolvimento para Reutilização (DRU): o propósito deste processo é identificar oportunidades de reutilização e, se possível, estabelecer um programa de reutilização, verificando a potencialidade de determinado produto ou bem de ser ou não reutilizado.
II) Gerência de Decisões (GDE): analisa possíveis decisões críticas usando processos formais, com critérios estabelecidos, para avaliação das alternativas identificadas.
III) Gerência de Riscos (GRI): é responsável por identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto.
4.3.4.6. Nível B – Gerenciado Quantitativamente.
Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao C). Neste nível o processo de Gerência de Projetos sofre sua segunda evolução, sendo acrescentados novos resultados para atender aos objetivos de gerenciamento quantitativo. Este nível não possui processos específicos.
4.3.4.7. Nível A – Em Otimização.
Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao B). Este nível não possui processos específicos.
5. PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS DE SOFTWARE BRASILEIRO (MPS.BR) EM INSTITUIÇÕES DO TIPO FÁBRICA DE SOFTWARE.
O principal ponto pretendido com a aplicação deste nível de maturidade é que a organização em questão, quando alcançar a maturidade de nível G, seja capaz de, gerenciar parcialmente seus projetos de desenvolvimento de software. Uma vez que, as empresas, em sua grande maioria, muitas vezes tem um esquema de processos, mas cada vez que algum imprevisto ocorre, por alguma dificuldade encontrada pelos servidores e colaboradores, este curso é abandonado e se dá continuidade para o andamento das atividades de forma desregrada e fora dos padrões.
Esse método de organização informal é um dos principais motivos da falta de planejamento e padronização das instituições. A aplicação de normas, processos bem definidos e métodos de melhoria de software tem tudo para fazer com que a empresa alcance diversos benefícios, além de chegar ao ponto em que erros poderão ser evitados e gastos reduzidos. O nível G de maturidade é o primeiro passo para o início de todo esse processo de melhorias e desmistificação de normas e regras.
Segundo o Guia de Implementação parte 1 (2009), dois (2) pontos são desafiadores na implantação do nível G. O primeiro diz respeito à mudança de cultura dentro da própria organização, orientando a definição e melhoria dos processos de desenvolvimento de software. E o segundo, seria a definição do conceito acerca do que é “projeto” para a organização.
