Mps Br Melhoria do Processo de Software Brasileiro Elisângela Beatriz Sodré. 1 â Introduà à o

Transcrição

1 Mps Br Melhoria do Processo de Software Brasileiro Elisângela Beatriz Sodré 1 â Introduà à o A indãºstria brasileira de software foi incluã da na polã tica industrial do governo para as exportaã ões e tem metas previstas de alcanã ar US$ 2 bilhãµes em exportaã ões atã Foi criado um convãªnio com a Agência de Promoà ões de Exportaà ões (Apex) juntamente com a proposta do Conselho Nacional de Desenvolvimento Industrial de criar uma polã tica de tributos especã fica para empresas interessadas em exportar. Segundo o presidente da Associaà à o Brasileira das Empresas de Software (Abes) Jorge Sukarie Neto, o paã s tem potencial para atingir as metas previstas pelo governo, desde que as empresas se organizem e que contem com apoio governamental. O grande desafio das empresas à dispor de mã o-de-obra qualificada e se adequar à s normas internacionais, garantindo nã o somente a qualidade dos produtos, mas tambã m ter certificaã ões internacionais como a CMM (Capability Maturity Model). A maior parte das empresas brasileiras,,possui metodologias de desenvolvimento, mas apenas uma pequena parte possui certificaã à o de maturidade de processos (CMM) de nã vel internacional na fabricaã à o de software sendo que, destas, a grande parte à multinacional. No que diz respeito à capacitaã à o do processo, observa-se que apenas uma pequena parte possui certificaã à o de elevada maturidade no seu processo de desenvolvimento de software. Dentre as empresas com certificaã à o (CMM/ISO), a maioria estã associada a produtos, enquanto as empresas de serviã os empregam mã todos prã³prios, mas sem certificaã à o, criando uma lacuna importante do ponto de vista de afirmaã à o internacional. As certificaã ões destas empresas estã o associadas a produtos, enquanto que as empresas de serviã os empregam mã todos prã³prios, mas sem certificaã à o formalizada. A tabela abaixo mostra que o conjunto de empresas com modelo de negã³cios centrados em produto â embarcado / componente e produto customizã vel â possui 80% das certificaã ões Bom e à timo. Maturidade do Processo x Modelo de Negócios A qualidade de software depende da capacitaã à o dos processos. Hà pouco investimento das empresas em certificaã ões que comprovem a qualidade e a maturidade dos seus processos na fabricaã à o de software, impossibilitando a venda deste produto no mercado internacional. Para as pequenas empresas, esse investimento à dificultado devido ao alto valor das certificaã ões. Graà as à iniciativa de entidades privadas, centros de estudos e governo brasileiro, existe a possibilidade de melhorarmos os processos de software no Brasil, tendo como foco pequenas e mã dias empresas. O Projeto mps BR â Melhoria de Processo do Software Brasileiro, projeto coordenado pela SOFTEX à apontado como soluã à o para tornar o software brasileiro um produto de exportaã à o competitivo. 2 â Quem à a SOFTEX? A Sociedade para Promoà à o da Excelência do Software Brasileiro (SOFTEX) à a entidade responsã vel pelo Programa SOFTEX, que tãªm como objetivo o apoio à produã à o e comã rcio do software brasileiro. Criado pelo CNPq em 1993 como Programa Softex 2000, foi r reformulado juntamente com a SOFTEX, de acordo com a nova polã tica brasileira de software e as

2 necessidades da nova economia. A sociedade SOFTEX à uma entidade privada, com sede em Campinas(SP), sem fins lucrativos, que promove aã ões de empreendedorismo, capacitaã à o, apoio à capitalizaã à o e ao financiamento, e apoio a geraã à o de negã³cios no Brasil e no exterior, visando aumentar a competitividade da indãºstria brasileira de software. Sua missã o à transformar o Brasil em um centro de excelãªncia mundial na produã à o e exportaã à o de software. A SOFTEX coordena as aã ões de 31 agentes SOFTEX, localizados em 23 cidades de 13 unidades da federaã à o, com mais de 300 empresas associadas. 3 â O Projeto mps BR Iniciado em 2003, a partir de dezembro, conta com a participaã à o de sete instituiã ões brasileiras: a SOFTEX, coordenadora do projeto; trãªs instituiã ões de ensino, pesquisa e centros tecnolã³gicos (COPPE / UFRJ, CESAR, CenPRA); uma sociedade de economia mista, a companhia de Informà tica do Paranà (CELEPAR), hospedeira do Subcomitê de Software da Associaà à o Brasileira de Normas Tà cnicas (ABNT); e duas organizaã ões nã o governamentais integrantes do Programa SOFTEX (Sociedade Núcleo de Apoio à Produà à o e Exportaà à o de Software do Rio de Janeiro â RIOSOFT e Sociedade Núcleo SOFTEX 2000 de Campinas). A Universidade Católica de Brasà lia tambã m faz arte do projeto. O projeto tem as seguintes metas: - Definir e implementar o Modelo de Referência para Melhoria de Processos de Software (MR mps) em 120 empresas, atã junho de 2006, com perspectiva de mais de 160 empresas nos dois anos subseqã¼entes. - Criar cursos em diversos locais do paã s para capacitar e formar consultores do modelo. - Credenciar instituiã ões e centros tecnolã³gicos capacitados a implementar e avaliar o modelo com foco em grupo de empresas. Foram criados dois modelos: o Modelo de Referência para Melhoria do Processo de Software (MR mps). e o Modelo de Negócio para Melhoria de Processo de Software (MN mps). Este modelo de negã³cios prev㪠duas situaã ões: -A implementaã à o do MR mps de forma personalizada para uma empresa (MNE â Modelo de Negócio Especà fico); -A implementaã à o do MR mps de forma cooperada em grupo de empresas (MNC â Modelo de Negócio Cooperado), à um modelo mais acessã vel à s micro, pequenas e mã dias empresas por dividir de forma proporcional parte dos custos entre as empresas e por se buscar outras fontes de financiamento Credenciamento e Avaliaà à o O credenciamento serã feito pelo Fórum de Credenciamento e Controle (FCC) do Projeto. No MNE, cada empresa negocia e assina um contrato com uma das instituiã ões credenciadas para Implementaà à o (ICI) do MR mps e, para avaliaã à o, assina um outro contrato especã fico com uma Instituià à o Credenciada para Avaliaà à o (ICA). No MNC, reãºne se um grupo de empresas sob um coordenador ou grupo de coordenadores, que toma a mesma iniciativa descrita anteriormente no que condiz a implementaã à o e avaliaã à o

3 do MR mps. 4 - Modelo e Normas que compãµe o MR mps Nà o à objetivo do projeto definir algo novo em termos de normas e modelo de maturidade. Para a construã à o do modelo foi observado a realidade das empresas brasileiras, a norma ISO/IEC 12207, a sã rie de normas ISO/IEC (SPICE) e o modelo CMMI, descritas abaixo Norma ISO/IEC Publicada internacionalmente em 1995 e no Brasil em 1998, passou por uma atualizaã à o em 2002 para acompanhar a evoluã à o da engenharia de software, as necessidades vivenciadas pelos usuã rios da norma e a harmonizaã à o com a sã rie de normas ISO/IEC15504 â Avaliaà à o de processos de software. Ela estabeleceu uma estrutura comum para os processos de ciclo de vida de software para ajudar as organizaã ões a obter um melhor entendimento das atividades a serem executadas nas operaã ões que envolvem de alguma forma o software. A estrutura da norma à composta de processos, atividades e tarefas que envolvam o software. A atualizaã à o de 2002 inseriu processos e acrescentou na sua descriã à o propã³sito e resultados de implementaã à o o que possibilita a avaliaã à o de capacidade do processo. A norma, incluindo o seu anexo à composta por: -Processos fundamentais: Aquisià à o, fornecimento, desenvolvimento, operaã à o e manutenã à o. -Processos de apoio: Documentaà à o, Gerência de configuraã à o, Garantia de qualidade, Verificaà à o, Validaà à o, Revisà o Conjunta, Auditoria, Resoluà à o de problemas e usabilidade. -Processos Organizacionais: Gerência, Infra-Estrutura, Melhoria, Recursos Humanos, Gestà o de Ativos, Gestà o de Programa de Reuso e engenharia de Domà nio. Cada processo à dividido em termos de suas prã³prias atividades e cada atividade à definida em termos de suas tarefas. A norma estabelece uma arquitetura de alto nã vel abrangendo desde a concepã à o atã a descontinuidade do software Norma ISO/IEC Em setembro de 1992, a ISO realizou um estudo chamado â œnecessidades e Exigências para uma Norma de Avaliaà à o de Processo de Softwareâ. O trabalho concluiu que era pertinente a elaboraã à o de um padrã o que fosse aplicã vel à melhoria de processos e a determinaã à o da capacidade. Este padrã o deveria considerar os mã todos e normas jã existentes e abranger todos os processos de software. A ISO/IEC (SPICE) foi publicada em 2003 e contempla a 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 organizaã à o. Se o objetivo for a melhoria de processos, a organizaã à o pode realizar a avaliaã à o gerando um perfil dos procesos que serã usado para a elaboraã à o de um plano de melhorias. A anã lise

4 dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a empresa 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. (Salviano, 2001, ISO/IEC,2003 ) CMMI O modelo SW-CMM (Capability Maturity Model) foi definido no 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, etc.) o que se mostrou problemã tico. O CMMI veio para resolver este problema, ele à a evoluã à o do SW-CMM, SECM e IPD-CMM. O modelo CMMI foi desenvolvido para ser compatã vel com a ISO/IEC (Chrissis, 2003). Existem dois tipos de representaã à o no CMMI: em estã gios e contã nua. A representaã à o em estã gios define um conjunto de à reas de processo para definir um caminho de melhoria para a organizaã à o, descrito em nã veis de maturidade. A representaã à o contã nua usa nã veis de capacidade para caracterizar melhoria relacionada a uma à rea de processo. Um modelo em estã gios fornece um roteiro prã -definido para melhoria de processos na organizaã à o baseado em agrupamento e ordenaã à o de processos. O termo â œestã giosâ vem da forma como o modelo descreve este roteiro, isto Ã, como uma sã rie de estã gios chamados nã veis de maturidade. Cada nã vel de maturidade tem um conjunto de à reas de processos que identificam onde a organizaã à o deve colocar o foco de forma a melhorar o seu processo. Cada à rea de processo à descrita em termos das prã ticas que contribuem para alcanã ar seus objetivos. O progresso ocorre pela satisfaã à o dos objetivos de todas as à reas de processo relacionadas a um determinado nã vel de maturidade. As à reas de processo do CMMI estã o organizadas em quatro nã veis de maturidade na representaã à o em estã gios, pois o nã vel um nã o possui à reas de processo. Aqui caberia um grã fico do CMMI, com os estã gios etc. 5â Implementaà à o MR mps A norma de referãªncia para os processos de ciclo de vida de software no MR mps à a ISO/IEC conforme sua atualizaã à o publicada em Esta norma pode ajudar a organizaã à p na definiã à o de seus processos pois ela contã m uma clara definiã à o da arquitetura, terminologia e responsabilidade, inerente a processos. Essa atualizaã à o inseriu processos e acrescentou na sua descriã à o propã³sito e resultados de implementaã à o o que possibilita a avaliaã à o de capacidade do processo. Ela à o guia para a definiã à o de processos. Os resultados esperados da implementaã à o dos processos sã o uma adaptaã à o para o MR mps dos resultados esperado nos processos e atividades da ISO/IEC A implementaã à o do MR mps pode ter soluã ões diferenciadas dependendo das caracterã sticas, necessidades e desejo das organizaã ões. Por exemplo, quando a organizaã à o deseja ter aderãªncia de seus processos ao CMMI esta pode se apoiar nas à reas de processos deste modelo para obter diretrizes sobre como definir e implementar os seus processos. A norma ISO/IEC 12207, por sua vez contã m atividades e tarefas descritas de forma detalhada que podem auxiliar na implementaã à o das à reas de processo. 6â Nà veis de Maturidade

5 Os nã veis de maturidade estabelecem uma forma de prever o desempenho futuro de uma organizaã à o com relaã à o a uma ou mais disciplinas. Um nã vel de maturidade à um patamar definido de evoluã à o de processo. No MR mps a maturidade do processo estã organizada em duas dimensãµes: - Dimensà o da capacidade: à um conjunto de atributos de um processo que estabelece o grau de refinamento e institucionalizaã à o com que o processo à executado na organizaã à o. à medida que evolui nos nã veis, um maior ganho de capacidade de desempenhar o processo à atingido pela organizaã à o. Os nã veis estabelecem uma maneira racional para aprimorar a capacidade dos processos definidos no MR mps. - Dimensà o de processos: baseada na ISO/IEC 12207, estabelece que a organizaã à o deveria executar para ter qualidade na produã à o, fornecimento, aquisiã à o e operaã à o de software. A interseã à o dessas duas dimensãµes define a maturidade do processo que no MR mps sã o sete nã veis de maturidade: A â Em Otimizaà à o B â Gerenciado Quantitativamente C â Definido D â Largamente Definido E â Parcialmente Definido F â Gerenciado G â Parcialmente Gerenciado Para cada um destes nã veis de maturidade citados acima, foram atribuã das à reas de processo, com base nos nã veis 2, 3,4 e 5 do CMMI em estã gios. Esta divisã o tem uma gradaã à o diferente do CMMI em estã gios como objetivo de possibilitar uma implementaã à o mais gradual e adequada à s micro, pequenas e mã dias empresas brasileiras. A possibilidade de realizar avaliaã ões considerando mais nã veis permite uma visibilidade dos resultados de melhoria do processo, na empresa e no paã s, com prazos mais curtos. Para cada à rea de processo sã o considerados objetivos e prã ticas especã ficas, de acordo com o nã vel de maturidade em questã o. 7 â Mà todos de Avaliaà à o A avaliaã à o das organizaã ões segundo o MR mps deverã ser realizada considerando-se a aderãªncia à s à reas de processo estabelecidas para cada nã vel de maturidade e a adequaã à o das prã ticas que implementam as à reas de processo. O mã todo de avaliaã à o foi definido com base na ISO/IEC O nã vel de implementaã à o das prã ticas relacionadas a uma à rea de processo à avaliada a partir de indicadores. Esses indicadores, que devem ser definidos pela empresa para cada prã tica relacionada a uma à rea de processo, podem ser de um dos trãªs tipos a seguir: -Direto: Sà o produtos intermediã rios, resultantes de uma atividade. -Indicadores Indiretos: Sà o, em geral, documentos que indicam que uma atividade foi realizada. -Afirmaà ões: Sà o resultantes de entrevistas com a equipe dos projetos avaliados de acordo com quatro nã veis: TI (Totalmente implementada), LI (Largamente Implementada), PI (Parcialmente Implementada), NI (Nà o Implementada). A decisã o final sobre o grau de implantaã à o de um processo à da equipe de avaliaã à o considerando os resultados da avaliaã à o nos projetos avaliados.

6 Uma empresa à considerada nã vel A, B, C, D, E, F ou G se todas as suas à reas, unidades, divisãµes ou setores tiverem sido avaliados como naquele nã vel. Uma empresa, entretanto pode desejar ter avaliado apenas um ou alguns de seus setores, à reas, unidades ou divisãµes (organizaã à o a ser avaliada). à possã vel que, como resultado de uma ou mais avaliaã ões, partes de uma empresa tenham alcanã ado um determinado nã vel e partes da mesma um outro nã vel. (nã o entendi Em qualquer caso, o documento comprobatã³rio da avaliaã à o deverã explicitar o que foi objeto da avaliaã à o (escopo da avaliaã à o) e o nã vel resultante da maturidade. Para realizaã à o de uma avaliaã à o devem ser submetidos todos os projetos concluã dos e todos os projetos em andamento a partir da implementaã à o do MR mps na empresa ou na organizaã à o que serã avaliada. Durante o planejamento da avaliaã à o, a instituiã à o avaliadora deve selecionar um conjunto suficiente de projetos que garanta representatividade da organizaã à o a ser avaliada. Este nãºmero, entretanto nã o deve ser inferior a dois projetos concluã dos e dois projetos em andamento. Algumas empresas podem desenvolver um único produto. Isto, entretanto nã o à impedimento para avaliaã à o, pois projetos sã o entendidos em sentido amplo, incluindo projetos de manutenã à o no produto. O resultado de uma avaliaã à o tem validade de dois anos. 8 - Conclusà o Projetos como este sã o importantes, porque criam possibilidades para micro, pequenas e mã dias empresas melhorarem os seus processos de software. Atravà s dele, as empresas brasileiras podem se tornar mais competitivas e oferecerem produtos desenvolvidos com a mesma qualidade de empresas internacionais. A base do projeto compreende normas internacionais usadas por boa parte das empresas no mundo, isto prova que a parceria entre governo e sociedade civil pode resultar em bons projetos para as empresas brasileiras. 9 â Referências Bibliogrà ficas - Site: - Artigo: Modelo de Referência para Melhoria de Processo de Software: uma abordagem brasileira XXX Conferência Latinoamericana de Informà tica (CLEI 2004), Arequipa Peru - Fonte: (O ESTADà O) O setor foi incluã do na polã tica industrial do governo Lula e tem como meta atingir US$ 2 bilhãµes em exportaã ões atã 2007 â 24/02/ (Weber, 2001) Weber, Kival. Chaves, Rocha Ana Regina Calvacanti, Nascimento; Joseli do Nascimento.Qualidade e Produtividade de Software 4ª Edià à o Renovada. Sà o Paulo, Makroon Books 2001