UNIVERSIDADE ESTADUAL DE CAMPINAS

Transcrição

1 UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE TECNOLOGIA Daniele Januario Gisele Pompeu Roberta Mayumi Matsunaga QUALIDADE DE SOFTWARE: ESTUDO E PROPOSTA DE IMPLEMENTAÇÃO DO NÍVEL G DO MPS.BR NA EQUIPE DE INFORMÁTICA DA DIRETORIA GERAL DE RECURSOS HUMANOS - DGRH LIMEIRA 2010

2 Daniele Januario Gisele Pompeu Roberta Mayumi Matsunaga QUALIDADE DE SOFTWARE: ESTUDO E PROPOSTA DE IMPLEMENTAÇÃO DO NÍVEL G DO MPS.BR NA EQUIPE DE INFORMÁTICA DA DIRETORIA GERAL DE RECURSOS HUMANOS - DGRH Monografia apresentada a Universidade Estadual de Campinas como um dos pré-requisitos para a conclusão da disciplina FT027 Tópicos de Computação. Profº Dr. Marcos Augusto F. Borges LIMEIRA 2010

3 RESUMO Atualmente tem sido um grande desafio para o mercado desenvolver produtos com qualidade. É necessário um controle amplo sobre o processo de desenvolvimento. A análise de requisitos e o cumprimento de prazos e custos devem ser seguidos rigorosamente para que as expectativas do cliente sejam atendidas. Há várias metodologias de melhoria de processos no mercado, e nessa monografia será apresentada a MPS.BR cuja adoção depende diretamente da preparação dos membros envolvidos, como veremos mais adiante. O presente trabalho apresenta um levantamento teórico sobre MPS.BR, dois estudos de caso e uma estratégia para implementação do nível G do MPS.BR na Equipe de informática na Diretoria Geral de Recursos Humanos UNICAMP. ABSTRACT Today has been a major challenge for the market to develop products with quality. What is needed is a comprehensive control over the development process. The analysis of requirements and meeting deadlines and costs should be followed strictly so that customer s expectations are met. There are several process improvement methodologies on the market, and in this monograph will be presented the MPS. BR whose adoption depends directly on the preparation of the members involved, as we will see later. This work presents a theoretical survey on MPS. BR, two case studies and a strategy for implementation of level G of MPS. BR in the IT section of the Human Resources Department of UNICAMP.

4 LISTA DE FIGURAS Figura 1: Números do SW-CMMI no Brasil em Figura 2: Estrutura do Programa MPS.BR (SOFTEX, 2006) Figura 3: Níveis do MPS.BR x Níveis do SW/CMMI Figura 4: Índice do Plano de Projeto (LEHRER, 2007) Figura 5: Índice do documento de requisitos (LEHRER, 2007) Figura 6: Organograma da Equipe de Informática da DGRH Figura 7: Problemas x Expectativas... 27

5 LISTA DE TABELAS Tabela 1: Atributos relacionados à qualidade do software (SOMMERVILE, 2008)... 9 Tabela 2: Níveis e respectivos processo (SOFTEX, 2006) Tabela 3: Processo de implementação do MPS.BR (SOFTEX, 2010) Tabela 4: Escopo do projeto Mps-Pdbl... 24

6 SUMÁRIO 1. INTRODUÇÃO PROCESSOS DE SOFTWARE QUALIDADE DE SOFTWARE CERTIFICAÇÃO MPS.BR HISTÓRICO ESTRUTURA NÍVEIS DE MATURIDADE NÍVEL G GERÊNCIA DE PROJETOS (GPR) GERÊNCIA DE REQUISITOS (GRE) PROCESSO DE IMPLEMENTAÇÃO ESTUDOS DE CASO ESTUDO DE CASO - ICODES ESTUDO DE CASO - PRODABEL IMPLEMENTAÇÃO NA DIRETORIA GERAL DE RECURSOS HUMANOS (DGRH) A EQUIPE DE INFORMÁTICA DA DGRH OBJETIVOS DA IMPLANTAÇÃO ABORDAGEM IDEAL IMPLANTAÇÃO DA GERÊNCA DE PROJETOS (GPR) IMPLANTAÇÃO DA GERÊNCIA DE REQUISITOS (GRE) DIFICULDADES ENCONTRADAS CONCLUSÃO REFERÊNCIAS... 34

7 7 1. INTRODUÇÃO É imprescindível que as grandes empresas produtoras de software entreguem produtos de qualidade. Os produtos têm de atender a todas as necessidades e expectativas do cliente, assim como o cumprimento de custos, prazos e requisitos definidos. Alguns padrões de qualidade surgiram para apoiar as empresas a desenvolverem software de qualidade. As empresas certificadas com esses padrões têm mais confiança do cliente. O certificado garante que a empresa irá produzir o software dentro das normas estabelecidas e, consequentemente, dentro do esperado pelo cliente. Um dos padrões existentes é o MPS.BR, (Melhoria de Processo de Software Brasileiro) modelo que tem por objetivo atingir as micro, pequenas e médias empresas brasileiras de produção de software. Ao contrário de padrões internacionais, como o CMMI, a adoção do MPS.BR não é demorada e tem um custo acessível. A presente monografia vai descrever o programa MPS.BR e realizar dois estudos de casos de empresas que o implantaram. Posteriormente, serão descritas as estratégias usadas para implantar o nível G do MPS.BR na Equipe de Informática da Diretoria Geral de Recursos Humanos (DGRH).

8 8 2. PROCESSOS DE SOFTWARE Processo de software é todo agrupamento de atividades que quando executadas levam à produção de um produto de software (SOMMERVILLE, 2008). Todos os processos de software têm em comum quatro atividades fundamentais: especificação, desenvolvimento, validação e evolução do software (PRESSMAN, 2002; SOMMERVILLE, 2008). Estas fases independem do tamanho, complexidade e finalidade do software, ou seja, são inerentes a todos os processos de produção de software. 3. QUALIDADE DE SOFTWARE Dentro do domínio da engenharia de software, a qualidade é a área responsável pela definição e normatização do desenvolvimento de produtos. Tem como objetivo atender às necessidades do cliente. Quando o domínio é o desenvolvimento do software, a qualidade esta diretamente relacionada à melhoria do processo de desenvolvimento. Segundo Sommerville (2008), os atributos essenciais de um bom software são: CARACTERÍSTICAS DO PRODUTO Facilidade de manutenção Confiança Eficiência DESCRIÇÃO O software deve ser desenvolvido para atender às necessidades de mudança futura dos clientes. Um software tem que ser confiável e seguro. Não pode causar dano de nenhuma natureza. O software deve usar os recursos do sistema de forma eficiente.

9 9 Usabilidade O software deve apresentar interface e documentação adequada para o usuário. Tabela 1: Atributos relacionados à qualidade do software (SOMMERVILE, 2008) Dentre os problemas encontrados no processo de desenvolvimento de software, Kosciansk (2007), elencou alguns como os mais relevantes: cronogramas mal elaborados; projetos complexos que são abandonados pela sua dificuldade; módulos que, quando interligados, não operam; software que não atendem aos requisitos; software de difícil usabilidade; software que pára de funcionar. A melhoria do processo de software tem como intuito mitigar os erros, aperfeiçoar a produtividade e facilitar a manutenção. A melhoria envolve a análise da situação atual, a avaliação de novas tecnologias e a implantação da tecnologia que tem melhoria comprovada (CORTÊS et al, 2001). 4. CERTIFICAÇÃO A certificação é a garantia de que uma empresa possui o processo de desenvolvimento de software em conformidade com as normas especificadas (CORTÊS et al, 2001). Pode ser feita a pedido da empresa ou do cliente e geralmente é realizada por uma empresa credenciada. Pode-se considerar a certificação como um indicador de que a empresa atende a padrões mínimos de qualidade. Por este motivo, ter um certificado de qualidade de software serve como moeda para negociar produtos ou serviços entre empresas.

10 10 5. MPS.BR Melhoria de Processo do Software Brasileiro (MPS.BR) é um programa de melhoria de software brasileiro que visa certificar empresas que sigam os padrões de qualidade que ele propõe. Sua estrutura foi criada para garantir que as empresas certificadas entreguem produtos de qualidade e que atendam as expectativas do cliente. O programa foi criado alinhado as necessidades do mercado em relação à qualidade de software. Abaixo serão descritos o histórico, a estrutura, os níveis de maturidade e o processo de implementação para adoção do modelo de qualidade. 5.1 HISTÓRICO De acordo com a SOFTEX (2006, p.5): Em 2003, no início da concepção do MPS.BR, dados da Secretaria de Política de Informática e Tecnologia do Ministério da Ciência e Tecnologia (MCT/SEITEC), mostravam que apenas 30 empresas no Brasil possuíam avaliação SW-CMM (Capability Maturity Model): 24 no nível 2; 5 no nível 3; 1 no nível 4; e nenhuma no nível 5. Foi concluído que as empresas que buscavam qualidade no processo de software no Brasil podiam ser divididas em dois grupos: empresas exportadoras de software e grandes empresas que desejavam atingir níveis mais altos de maturidade (SOFTEX, 2006). A pirâmide da Figura 1 demonstra os números do SW-CMMI no Brasil em 2003 e salienta que o topo da pirâmide era formado por empresas exportadoras de software e grandes empresas. Na base da pirâmide estão as micro, pequenas e médias empresas.

11 11 Figura 1: Números do SW-CMMI no Brasil em Os números deixam clara a dificuldade da adoção do SW-CMMI devido ao custo e demora (o processo pode levar de 4 a 10 anos). Percebeu-se então a necessidade da criação de um processo de qualidade de software brasileiro. Neste contexto, começou a ser implementado o MPS.BR em dezembro de O desenvolvimento é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), que conta com o apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID) (SOFTEX, 2006). A coordenação do Programa MPS.BR conta com o apoio do Fórum de Credenciamento e Controle (FCC) e da Equipe Técnica do Modelo (ETM) (SOFTEX, 2006). Ambos dão apoio ao desenvolvimento do MPS.BR, obtendo a participação de representantes de universidades, instituições governamentais, centros de pesquisa e organizações privadas. A base técnica para construção e aprimoramento do MPS.BR é composta pelas normas NBR ISSO/IEC Processo de Ciclo de Vida de Software, pelas emendas 1 e 2 da norma internacional. Conta também com as normas ISSO/IEC e ISSO/IEC Avaliação de Processo (SOFTEX, 2006). Para complementação, é utilizado também o modelo CMMI-SE/SW.

12 12 O MPS.BR visa construir um processo de melhoria de software para micro, pequenas e médias empresas, porém, não fica restrito a empresas de pequeno porte, podendo atingir também as grandes empresas como veremos mais adiante. 5.2 ESTRUTURA A estrutura do MPS.BR é complexa. Está dividida em três modelos: Modelo de Referência (MR-MPS), Modelo de Negócios (MN-MPS) e Método de Avaliação (MA- MPS). Estes modelos estão apoiados em três documentos: Guia Geral, Guia de Aquisição e Guia de Avaliação (SOFTEX, 2006). A Figura 2 demonstra a estrutura e por quais documentos os modelos são apoiados. Figura 2: Estrutura do Programa MPS.BR (SOFTEX, 2006) Os guias podem ser encontrados no site da SOFTEX (2010) para download. Os modelos são descritos abaixo (SOFTEX, 2006):

13 13 Modelo de Referência (MR-MPS): contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MPS.BR. Apresenta as definições dos níveis de maturidade, processos e atributos do processo. O modelo encontra-se descrito no Guia Geral e também é apoiado pelo Guia de Aquisição que descreve as boas práticas para organizações que pretendem adquirir software e serviços; Modelo de Negócio (MN-MPS): contém regras de negócio para a implementação do MR-MPS pelas Instituições Implementadoras (II); Método de Avaliação (MA-MPS): contém os métodos que as Instituições Avaliadoras (IA) têm de seguir para avaliar uma organização que pretende estar no Programa MPS.BR. É apoiado pelo Guia de Avaliação que descreve os métodos e processos de avaliação bem como os requisitos para avaliadores líderes e avaliadores adjuntos. Durante a descrição dos modelos, foram introduzidas duas novas nomenclaturas presentes na estrutura do MPS.BR: a Instituição Avaliadora (IA) e a Instituição Implementadora (II). A IA e II são instituições credenciadas pelo Fórum de Credenciamento e Controle (FCC), a primeira é a avaliadora do MPS.BR e a segunda implementadora do MR-MPS. 5.3 NÍVEIS DE MATURIDADE Uma vez que a estrutura já foi apresentada, é importante conhecer também os níveis de maturidade do MPS.BR. Os níveis vão de A até G, sendo o nível G o mais baixo. Os níveis de maturidade estabelecem níveis de evolução no processo de desenvolvimento de software. A partir do nível de maturidade é possível prever o desempenho da organização ao executar processos futuros.

14 14 Embora a divisão dos níveis tenha sido baseada na existente no CMMI, o MPS.BR possui graduação e classificação diferentes, pois tem como objetivo maior adoção de micro, pequenas e médias empresas. A Figura 3 demonstra os sete níveis do MPS.BR e a respectiva correspondência com os níveis de maturidade do CMMI. Figura 3: Níveis do MPS.BR x Níveis do SW/CMMI Cada nível possui processos que indicam onde a organização deve focar para implantar a melhoria. O alcance de níveis se deve ao atendimento de todos os resultados esperados para os respectivos níveis. Não é foco deste trabalho descrever detalhadamente o MPS.BR, portanto, os níveis (exceto o nível G) não serão aqui descritos. Para maiores informações sobre os níveis, o Guia Geral elaborado pela SOFTEX poderá ser consultado. Na Tabela 2, há uma listagem de quais processos estão presentes em cada nível. NÍVEL A (Em Otimização) B PROCESSOS Implantação de Inovações na Organização (IIO) Análise de Causas e Resoluções (ARC) Desempenho do Processo Organizacional (DEP)

15 15 (Gerenciado Gerência Quantitativa do Projeto (GQP) Quantitativamente) C Análise de Decisão e Resolução (ADR) (Definido) Gerência de Riscos (GRI) D Desenvolvimento de Requisitos (DRE) (Largamente Definido) Integração do Produto (ITP) Solução Técnica (STE) Validação (VAL) Verificação (VER) E Adaptação do Processo para Gerência do Projeto (APG) (Parcialmente Definido) Avaliação e Melhoria do Processo Organizacional (AMP) Definição do Processo Organizacional (DFP) Treinamento (TRE) F Processo de Aquisição (AQU) (Gerenciado) Gerência de Configuração (GCO) Garantia da Qualidade (GQA) Processo de Medição (MED) G Gerência de Projetos (GPR) (Parcialmente Gerenciado) Gerência de Requisitos (GRE) Tabela 2: Níveis e respectivos processos (SOFTEX, 2006) NÍVEL G Como iremos implantar o nível G, ele será descrito detalhadamente nesta seção. O nível G é o primeiro nível de maturidade do MPS.BR. Por esse motivo, tem de ser executado com cautela. Segundo a Softex (2009), ao final da implantação a organização será capaz de gerenciar parcialmente seus projetos de software. A implantação do nível G apresenta

16 16 dois grandes desafios para a organização: a necessidade da mudança cultural da empresa e a redefinição do que é projeto para a organização. Faz parte do nível G a implementação da Gerência de Projeto e de Requisitos que serão descritas detalhadamente nas próximas seções GERÊNCIA DE PROJETOS (GPR) O nível G tem como propósito a definição de planos para o projeto que envolva o estabelecimento prévio de atividades, recursos e responsabilidades. Provê também informações sobre o andamento do projeto e permite a alteração quando houver mudanças. Segundo a SOFTEX (2009), a Gerência de Projetos pode ser definida como: O processo Gerência de Projetos (GPR) envolve várias atividades, como: desenvolver um plano geral de controle do projeto; obter o comprometimento e mantê-lo ao longo de toda a execução do projeto; e conhecer o progresso do projeto, de maneira que ações corretivas possam ser tomadas quando a execução do projeto desviar do planejado. No plano de projeto estão previstos o planejamento e a execução de monitorias no escopo, riscos, prazos e recursos. Durante o monitoramento, o plano de projeto pode ser refeito para acompanhar as mudanças do projeto. Para a fundamentação teórica pode-se utilizar o PMBOK (Project Management Body of Knowledge) do PMI (Project Management Institute). O PMBOK é uma guia em gerência de projetos. Ele agrupa conhecimento e boas práticas para gerenciamento. Os resultados que devem ser atingidos com a Gerência de projeto estão listados abaixo (SOFTEX, 2009):

17 17 GPR 1. O escopo do trabalho para o projeto está definido; GPR 2. O escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados; GPR 3. As fases do ciclo de vida do projeto são definidas; GPR 4. A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados; GPR 5. As tarefas, os recursos e a infra-estrutura necessários para completar o trabalho são planejados; GPR 6. O cronograma e o orçamento do projeto são estabelecidos e mantidos; GPR 7. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridades de tratamento são determinados e documentados; GPR 8. Os dados relevantes do projeto são identificados, coletados, armazenados e distribuídos. Um mecanismo é estabelecido para acessá-los, incluindo (se pertinente) questões de privacidade e segurança; GPR 9. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo; GPR 10. O esforço e o custo para os produtos de trabalho e tarefas são estimados baseados em dados históricos ou referências técnicas; GPR 11. O envolvimento dos interessados no projeto é planejado; GPR 12. O planejamento do projeto é revisado com todos os interessados e o compromisso com o mesmo é obtido; GPR 13. O planejamento do projeto é monitorado no que se refere a cronograma, custos, recursos, riscos, envolvimento dos interessados e dados; GPR 14. Revisões são realizadas em marcos do projeto conforme estabelecido no planejamento; GPR 15. Registros e análise dos problemas identificados nas monitorações são estabelecidos; GPR 16. Ações corretivas são estabelecidas quando necessário e gerenciadas até a sua conclusão.

18 GERÊNCIA DE REQUISITOS (GRE) O propósito da Gerência de Requisitos é gerenciar requisitos tanto dos produtos como dos componentes identificando e controlando inconsistências entre os requisitos e os produtos desenvolvidos. Segundo a SOFTEX (2009), a Gerência de Requisitos pode ser definida como: O processo Gerência de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais e nãofuncionais, bem como os requisitos impostos ao projeto pela organização. O requisitos devem ser acordados entre organização e cliente para evitar mau entendimento antes que o requisito entre no escopo do projeto. Toda mudança de requisito deve ser adequadamente documentada. Para a definição adequada de requisitos, existe a necessidade de boa comunicação entre empresa e cliente. Os requisitos têm de ser definidos e aprovados, e caso necessário, alterados de acordo com a solicitação do cliente. Os resultados esperados com a implementação da Gerência de Requisitos são (SOFTEX, 2009): GRE 1: Uma comunicação contínua com os fornecedores de requisitos é estabelecida; GRE 2: O entendimento dos requisitos é obtido; GRE 3: A aceitação dos requisitos é estabelecida por meio de critérios objetivos; GRE 4: O comprometimento com os requisitos é estabelecido e mantido; GRE 5: A rastreabilidade entre os requisitos, os planos do projeto e os produtos de trabalho é estabelecida e mantida; GRE 6: Inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos são identificadas e corrigidas; GRE 7: Mudanças nos requisitos são gerenciadas ao longo do projeto.

19 PROCESSO DE IMPLEMENTAÇÃO O processo de implementação do MPS.BR é dividido conforme a tabela abaixo: SUBPROCESSO ATIVIDADE Pesquisar Instituições Avaliadoras Contratar avaliação Estabelecer contrato Viabilizar a avaliação Planejar a avaliação Preparar a realização da avaliação Preparar a avaliação Conduzir a avaliação inicial Completar a preparação da avaliação Conduzir a avaliação final Realizar a avaliação final Avaliar a execução do processo de avaliação Documentar os resultados da Relatar resultados avaliação Registrar resultados Tabela 3: Processo de implementação do MPS.BR (SOFTEX, 2010) Uma empresa que deseja obter a certificação MPS.BR deve acessar o site da SOFTEX e verificar as IA s disponíveis para a avaliação. A empresa deve então solicitar sugestões de avaliação destas instituições. As IA s irão responder às solicitações e a empresa deve então selecionar uma IA e enviar uma reposta às outras comunicando a instituição escolhida para realizar a avaliação. A seguir, é firmado um contrato entre a empresa e IA escolhida. No segundo subprocesso, a IA dará início ao processo burocrático que envolve: comunicar a SOFTEX, pagar taxas de serviço e comunicar à equipe que realizará a avaliação. A equipe de avaliação prepara o procedimento que abrange enviar um molde de avaliação para a organização contendo o projeto e o cronograma. Planilhas são preenchidas e uma avaliação inicial é realizada a partir dos dados fornecidos. A partir daí, a implementação e avaliação se inicia.

20 20 6. ESTUDOS DE CASO Dois estudos de caso foram realizados. O grupo pesquisou empresas que já possuem ou almejam o nível G da certificação MPS.BR. O primeiro estudo de caso que será apresentado será do Instituto Centro-Oeste de Desenvolvimento de Software (ICODES) e o segundo a empresa de Processamento de Dados do Município de Belo Horizonte (PRODABEL). 6.1 ESTUDO DE CASO - ICODES No artigo Processo de Desenvolvimento de Software em Conformidade com o Nível G do Modelo de Referência MPS.BR, Lehrer (2007) descreve a implementação do nível G do MPS.BR no Instituto Centro-Oeste de Desenvolvimento de Software (ICODES). O ICODES é um instituto de pesquisas e desenvolvimento de software localizado na cidade de Formosa - Goiás. Foi criado no primeiro trimestre de 2006 com uma equipe técnica que contava com cinco colaboradores, e na época que o artigo foi escrito, a empresa estava com nove colaboradores (LEHRER, 2007). O objetivo da implantação é alcançar processos mais maduros que equilibrem qualidade com produtividade. Além disso, a certificação equipararia o instituto com outros institutos ou empresas nacionais e internacionais na produção de software de qualidade. O autor relata então os esforços realizados para implantar a Gerência de Projetos e a Gerência de Requisitos. Tal implantação teve um esforço de quinhentas horas. Para a implantação da Gerência de Projetos, o instituto adotou o uso do Plano de Projeto para todos os projetos do ICODES. Neste documento, criado no início do projeto, é descrito o planejamento, acompanhamento e encerramento do projeto. O plano de projeto vai conter a periodicidade em que o projeto será acompanhado,

21 21 indicando reuniões e técnicas e de qualidade. A empresa adotou o uso da ata em toda reunião realizada. Durante o acompanhamento, o plano de projeto irá conter todos os monitoramentos necessários como: cronograma, custos, riscos, contratações etc. A Figura 4 mostra o índice do plano de projeto usado pela empresa: Figura 4: Índice do Plano de Projeto (LEHRER, 2007) Para a Gerência de Requisitos, o instituto irá realizar reuniões com os clientes até que os requisitos fiquem claros para ambas as partes. As reuniões serão realizadas com clientes e potenciais usuários do sistema. Antes das reuniões, os membros do ICODES já definirão quais os questionamentos que deverão ser abordados. Após cada reunião, um relatório será elaborado e deverá ser aprovado pelo cliente. Este processo

22 22 será realizado até que os requisitos estejam claros. Havendo algum requisito dúbio, os colaboradores do instituto deverão esclarecê-lo com o cliente. Após isso, é elaborado o documentos de requisitos, cujo índice esta na Figura 5: Figura 5: Índice do documento de requisitos (LEHRER, 2007) Lehrer (2007) descreve então algumas dificuldades encontradas. A primeira foi a barreira que os colaboradores colocaram na necessidade de realizar documentação de todas as reuniões. A segunda, a dificuldade que os gerentes de projetos tiveram ao realizar o Plano de Projeto logo no início do projeto. Os colaboradores chegaram até

23 23 mesmo a questionar o real benefício da adoção do programa. Tais dificuldades foram vencidas com o tempo através de conversas informais e demonstrações dos benefícios da implantação do MPS.BR. Até a escrita do artigo, o ICODES não havia realizado a avaliação, estava somente se preparando. O instituto pretendia com a certificação alcançar melhoria no processo de desenvolvimento e, conseqüentemente, aumentar a qualidade e produtividade de software. 6.2 ESTUDO DE CASO - PRODABEL O artigo Diagnóstico da Implantação da MPS.BR Nível G na Administração Pública: Estudo de Caso na Prodabel, Souza et al (2008) descreve a implementação do nível G na PRODABEL. A empresa Processamento de Dados do Município de Belo Horizonte (PRODABEL) é responsável por toda a gestão de tecnologia da informação da prefeitura municipal de Belo Horizonte. Presta serviços de desenvolvimento e manutenção de software, além de toda a infra-estrutura tecnológica. Atualmente, a empresa possui aplicações standalone, cliente-servidor e web. A equipe é composta de 480 colaboradores, sendo 130 de desenvolvimento de sistemas, e está distribuída por todo o município (unidades setoriais) (SOUZA et al, 2008). São desenvolvidos e mantidos aproximadamente 200 sistemas com tecnologias variadas. Além destes sistemas, há 50 projetos em andamento. São fatores que dificultam a padronização e qualidade no desenvolvimento de software: os diferentes níveis de capacitação, a descentralização das equipes de trabalho e, o grande volume de aquisição de serviços e produtos. As contratações de serviços podem compreender somente testes, todo o desenvolvimento do sistema e ainda a aquisição de pacotes prontos. A conseqüência de todos esses fatores foi a dificuldade de gerenciamento, prejudicando o custo, prazo, qualidade, e a falta de previsibilidade no desenvolvimento

24 24 de sistemas feitos tanto pela equipe quanto por contratação de terceiros. Com isso, a empresa busca por uma melhoria nos seus processos de software. O projeto de melhoria dos processos de software denominado MpsPdbl teve duração de 15 meses e foi organizado para atender os processos de Gerência de Requisitos (GRE) e Gerência de Projetos (GPR) da MPS.BR. O escopo do projeto dividiu-se em quatro etapas: ETAPAS DESCRIÇÃO Diagnóstico inicial Entrevistas, relatório e treinamento. Definição do processo Descrição do ciclo de vida do processo e disciplinas. Foram utilizadas as mesmas fases do Rational Unified Process (RUP). Projetos-piloto Projetos de software desenvolvidos com base nas definições do processo Avaliação Análise crítica, pré-avaliação e avaliação oficial do MPS.BR. Tabela 4: Escopo do projeto Mps-Pdbl As reuniões com a equipe ocorreram semanalmente e com a Instituição Implementadora, quinzenalmente. Nessas reuniões, foram avaliadas a implementação do projeto de melhoria, o andamento dos trabalhos, a adequação das soluções implementadas e a aderência do processo ao modelo. O maior problema encontrado foi que alguns membros sentiam-se perdidos no processo, pois não tinham conhecimento de conceitos fundamentais, como por exemplo, ciclo de vida de um projeto. Lições aprendidas: Necessidade de tratar melhor as diferenças de competência dos membros da equipe, respeitando a capacidade de cada um. Necessidade de treinamento em processo de software. 80 funcionários foram capacitados em cursos de Introdução ao processo de software, requisitos e análise. O consenso das decisões da equipe precisa ser mais ágil.

25 25 A melhor forma de se avaliar os resultados é a execução do processo em um projeto-piloto. Não aceitar comportamentos do tipo não conheço e não gostei. A PRODABEL foi a primeira empresa municipal de serviços de informática e a segunda empresa no Brasil certificada no MPS.BR, nível G. A avaliação foi feita em junho de IMPLEMENTAÇÃO NA DIRETORIA GERAL DE RECURSOS HUMANOS (DGRH) Pretende-se preparar a equipe de desenvolvimento de sistemas para a implantação do programa MPS.BR nível G. Para isso apresentaremos uma breve descrição da equipe, a abordagem IDEAL que será utilizada e os esforços realizados para a Gerência de Projetos e Requisitos (processos que são focos do nível G). Vale ressaltar que, por ora, não haverá certificação, a equipe vai somente desenvolver estratégias para a implementação. Caso a gerência aceite realizar a certificação terá de ser feito um processo de licitação para uma instituição avaliadora. Portanto, a presente monografia irá descrever somente o que fazer para implantar o nível G. 7.1 A EQUIPE DE INFORMÁTICA DA DGRH A Diretoria Geral de Recursos Humanos (DGRH) é a unidade que gerencia, planeja e executa as políticas de recursos humanos da Universidade Estadual de Campinas (UNICAMP). A equipe de informática é dividida em células conforme figura:

26 26 Figura 6: Organograma da Equipe de Informática da DGRH A DGRH utiliza alguns módulos de um pacote comprado da empresa Senior Sistemas, uma empresa de Blumenau Santa Catarina. O pacote, denominado Vetorh, é composto por vários módulos totalmente integrados. Apesar do aplicativo ser um produto fornecido por terceiros, a equipe de desenvolvimento da DGRH/Informática possui independência para manutenção dos módulos do sistema, podendo fazer alterações, como gerar relatórios e telas de consultas e cadastros, assim como implementações no banco de dados, como criar campos em tabelas nativas ou criar tabelas exclusivas para a UNICAMP. A base de dados é única. O banco de dados é Oracle e o sistema foi desenvolvido em Delphi. Além deste pacote, a equipe possui alguns sistemas WEB desenvolvidos em JAVA. Estes sistemas são desenvolvidos quando o projeto é específico da universidade e o pacote não atende. A implantação irá atingir a Célula Java e a Célula Vetorh por se tratarem das únicas que desenvolvem softwares.

27 OBJETIVOS DA IMPLANTAÇÃO A equipe de informática da DGRH não segue nenhum padrão de processo de desenvolvimento de software e não possui nenhuma certificação. Por este motivo, os projetos acabam ficando mal documentados, mal gerenciados e suscetíveis de falhas. A Figura 6 contém os problemas que a DGRH encontra e os benefícios que a implantação do MPB.BR irá trazer nos projetos da equipe. Figura 7: Problemas x Expectativas Espera-se que com a implantação do MPS.BR e em particular do nível G, a gerência tenha maior controle sobre o projeto e os requisitos sejam controlados de forma adequada. Tal meta só será possível com a motivação de toda equipe, esta meta pretende ser alcançada através de reuniões onde serão expostos os benefícios da implantação de um programa de melhoria.