UNIVERSIDADE ESTADUAL DE CAMPINAS

FACULDADE DE TECNOLOGIA

Daniele Januario Gisele Pompeu Roberta Mayumi Matsunaga

QUALIDADE DE SOFTWARE: ESTUDO E PROPOSTA DE IMPLEMENTAO DO NVEL G DO MPS.BR NA EQUIPE DE INFORMTICA DA DIRETORIA GERAL DE RECURSOS HUMANOS DGRH

LIMEIRA 2010

Daniele Januario Gisele Pompeu Roberta Mayumi Matsunaga

QUALIDADE DE SOFTWARE: ESTUDO E PROPOSTA DE IMPLEMENTAO DO NVEL G DO MPS.BR NA EQUIPE DE INFORMTICA DA DIRETORIA GERAL DE RECURSOS HUMANOS DGRH

Monografia apresentada a Universidade Estadual de Campinas como um dos pr-requisitos para a concluso da disciplina FT027 Tpicos de Computao.

Prof Dr. Marcos Augusto F. Borges

LIMEIRA 2010

RESUMO

Atualmente tem sido um grande desafio para o mercado desenvolver produtos com qualidade. necessrio um controle amplo sobre o processo de desenvolvimento. A anlise de requisitos e o cumprimento de prazos e custos devem ser seguidos rigorosamente para que as expectativas do cliente sejam atendidas. H vrias metodologias de melhoria de processos no mercado, e nessa monografia ser apresentada a MPS.BR cuja adoo depende diretamente da preparao dos membros envolvidos, como veremos mais adiante. O presente trabalho apresenta um levantamento terico sobre MPS.BR, dois estudos de caso e uma estratgia para implementao do nvel G do MPS.BR na Equipe de informtica 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 customers 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.

LISTA DE FIGURAS

Figura 1: Nmeros do SW-CMMI no Brasil em 2003. .................................................... 11 Figura 2: Estrutura do Programa MPS.BR (SOFTEX, 2006) .......................................... 12 Figura 3: Nveis do MPS.BR x Nveis do SW/CMMI ....................................................... 14 Figura 4: ndice do Plano de Projeto (LEHRER, 2007) .................................................. 21 Figura 5: ndice do documento de requisitos (LEHRER, 2007) ...................................... 22 Figura 6: Organograma da Equipe de Informtica da DGRH ......................................... 26 Figura 7: Problemas x Expectativas ............................................................................... 27

LISTA DE TABELAS

Tabela 1: Atributos relacionados qualidade do software (SOMMERVILE, 2008) .......... 9 Tabela 2: Nveis e respectivos processo (SOFTEX, 2006) ............................................ 15 Tabela 3: Processo de implementao do MPS.BR (SOFTEX, 2010) ........................... 19 Tabela 4: Escopo do projeto Mps-Pdbl .......................................................................... 24

SUMRIO

1. INTRODUO ............................................................................................................. 7 2. PROCESSOS DE SOFTWARE ................................................................................... 8 3. QUALIDADE DE SOFTWARE ..................................................................................... 8 4. CERTIFICAO........................................................................................................... 9 5. MPS.BR...................................................................................................................... 10 5.1 HISTRICO .......................................................................................................... 10 5.2 ESTRUTURA ........................................................................................................ 12 5.3 NVEIS DE MATURIDADE ................................................................................... 13 5.3.1 NVEL G............................................................................................................. 15 5.3.1.1 GERNCIA DE PROJETOS (GPR) ............................................................ 16 5.3.1.2 GERNCIA DE REQUISITOS (GRE) ......................................................... 18 5.4 PROCESSO DE IMPLEMENTAO.................................................................... 19 6. ESTUDOS DE CASO ................................................................................................. 20 6.1 ESTUDO DE CASO - ICODES ............................................................................. 20 6.2 ESTUDO DE CASO - PRODABEL ....................................................................... 23 7. IMPLEMENTAO NA DIRETORIA GERAL DE RECURSOS HUMANOS (DGRH) 25 7.1 A EQUIPE DE INFORMTICA DA DGRH ............................................................ 25 7.2 OBJETIVOS DA IMPLANTAO ......................................................................... 27 7.3 ABORDAGEM IDEAL ........................................................................................... 28 7.4 IMPLANTAO DA GERNCA DE PROJETOS (GPR) ...................................... 29 7.5 IMPLANTAO DA GERNCIA DE REQUISITOS (GRE) .................................. 31 7.6 DIFICULDADES ENCONTRADAS ....................................................................... 32 8. CONCLUSO............................................................................................................. 33 REFERNCIAS .............................................................................................................. 34

1. INTRODUO

imprescindvel que as grandes empresas produtoras de software entreguem produtos de qualidade. Os produtos tm de atender a todas as necessidades e expectativas do cliente, assim como o cumprimento de custos, prazos e requisitos definidos. Alguns padres de qualidade surgiram para apoiar as empresas a

desenvolverem software de qualidade. As empresas certificadas com esses padres tm mais confiana 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 padres existentes o MPS.BR, (Melhoria de Processo de Software Brasileiro) modelo que tem por objetivo atingir as micro, pequenas e mdias empresas brasileiras de produo de software. Ao contrrio de padres internacionais, como o CMMI, a adoo do MPS.BR no demorada e tem um custo acessvel. A presente monografia vai descrever o programa MPS.BR e realizar dois estudos de casos de empresas que o implantaram. Posteriormente, sero descritas as estratgias usadas para implantar o nvel G do MPS.BR na Equipe de Informtica da Diretoria Geral de Recursos Humanos (DGRH).

2. PROCESSOS DE SOFTWARE

Processo de software todo agrupamento de atividades que quando executadas levam produo de um produto de software (SOMMERVILLE, 2008). Todos os processos de software tm em comum quatro atividades fundamentais: especificao, desenvolvimento, validao e evoluo do software (PRESSMAN, 2002; SOMMERVILLE, 2008). Estas fases independem do tamanho, complexidade e finalidade do software, ou seja, so inerentes a todos os processos de produo de software.

3. QUALIDADE DE SOFTWARE

Dentro do domnio da engenharia de software, a qualidade a rea responsvel pela definio e normatizao do desenvolvimento de produtos. Tem como objetivo atender s necessidades do cliente. Quando o domnio o desenvolvimento do software, a qualidade esta diretamente relacionada melhoria do processo de desenvolvimento. Segundo Sommerville (2008), os atributos essenciais de um bom software so:

CARACTERSTICAS DO PRODUTO Facilidade de manuteno

DESCRIO

O software deve ser desenvolvido para atender s necessidades de mudana futura dos clientes.

Confiana

Um software tem que ser confivel e seguro. No pode causar dano de nenhuma natureza.

Eficincia

O software deve usar os recursos do sistema de forma eficiente.

Usabilidade

software

deve

apresentar

interface

documentao adequada para o usurio.

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 so abandonados pela sua dificuldade; mdulos que, quando interligados, no operam; software que no atendem aos requisitos; software de difcil usabilidade; software que pra de funcionar. A melhoria do processo de software tem como intuito mitigar os erros, aperfeioar a produtividade e facilitar a manuteno. A melhoria envolve a anlise da situao atual, a avaliao de novas tecnologias e a implantao da tecnologia que tem melhoria comprovada (CORTS et al, 2001).

4. CERTIFICAO

A certificao a garantia de que uma empresa possui o processo de desenvolvimento de software em conformidade com as normas especificadas (CORTS et al, 2001). Pode ser feita a pedido da empresa ou do cliente e geralmente realizada por uma empresa credenciada. Pode-se considerar a certificao como um indicador de que a empresa atende a padres mnimos de qualidade. Por este motivo, ter um certificado de qualidade de software serve como moeda para negociar produtos ou servios entre empresas.

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 padres de qualidade que ele prope. 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 relao qualidade de software. Abaixo sero descritos o histrico, a estrutura, os nveis de maturidade e o processo de implementao para adoo do modelo de qualidade.

5.1 HISTRICO

De acordo com a SOFTEX (2006, p.5):

Em 2003, no incio da concepo do MPS.BR, dados da Secretaria de Poltica de Informtica e Tecnologia do Ministrio da Cincia e Tecnologia (MCT/SEITEC), mostravam que apenas 30 empresas no Brasil possuam avaliao SW-CMM (Capability Maturity Model): 24 no nvel 2; 5 no nvel 3; 1 no nvel 4; e nenhuma no nvel 5.

Foi concludo 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 nveis mais altos de maturidade (SOFTEX, 2006). A pirmide da Figura 1 demonstra os nmeros do SW-CMMI no Brasil em 2003 e salienta que o topo da pirmide era formado por empresas exportadoras de software e grandes empresas. Na base da pirmide esto as micro, pequenas e mdias empresas.

11

Figura 1: Nmeros do SW-CMMI no Brasil em 2003.

Os nmeros deixam clara a dificuldade da adoo do SW-CMMI devido ao custo e demora (o processo pode levar de 4 a 10 anos). Percebeu-se ento a necessidade da criao de um processo de qualidade de software brasileiro. Neste contexto, comeou a ser implementado o MPS.BR em dezembro de 2003. O desenvolvimento coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), que conta com o apoio do Ministrio da Cincia e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID) (SOFTEX, 2006). A coordenao do Programa MPS.BR conta com o apoio do Frum de Credenciamento e Controle (FCC) e da Equipe Tcnica do Modelo (ETM) (SOFTEX, 2006). Ambos do apoio ao desenvolvimento do MPS.BR, obtendo a participao de representantes de universidades, instituies governamentais, centros de pesquisa e organizaes privadas. A base tcnica para construo e aprimoramento do MPS.BR composta pelas normas NBR ISSO/IEC 12207 Processo de Ciclo de Vida de Software, pelas emendas 1 e 2 da norma internacional. Conta tambm com as normas ISSO/IEC 12207 e ISSO/IEC 15504 Avaliao de Processo (SOFTEX, 2006). Para complementao, utilizado tambm o modelo CMMI-SE/SW.

12

O MPS.BR visa construir um processo de melhoria de software para micro, pequenas e mdias empresas, porm, no fica restrito a empresas de pequeno porte, podendo atingir tambm as grandes empresas como veremos mais adiante.

5.2 ESTRUTURA

A estrutura do MPS.BR complexa. Est dividida em trs modelos: Modelo de Referncia (MR-MPS), Modelo de Negcios (MN-MPS) e Mtodo de Avaliao (MAMPS). Estes modelos esto apoiados em trs documentos: Guia Geral, Guia de Aquisio e Guia de Avaliao (SOFTEX, 2006). A Figura 2 demonstra a estrutura e por quais documentos os modelos so apoiados.

Figura 2: Estrutura do Programa MPS.BR (SOFTEX, 2006)

Os guias podem ser encontrados no site da SOFTEX (2010) para download. Os modelos so descritos abaixo (SOFTEX, 2006):

13

Modelo de Referncia (MR-MPS): contm os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o MPS.BR. Apresenta as definies dos nveis de maturidade, processos e atributos do processo. O modelo encontra-se descrito no Guia Geral e tambm apoiado pelo Guia de Aquisio que descreve as boas prticas para organizaes que pretendem adquirir software e servios; Modelo de Negcio (MN-MPS): contm regras de negcio para a implementao do MR-MPS pelas Instituies Implementadoras (II); Mtodo de Avaliao (MA-MPS): contm os mtodos que as Instituies Avaliadoras (IA) tm de seguir para avaliar uma organizao que pretende estar no Programa MPS.BR. apoiado pelo Guia de Avaliao que descreve os mtodos e processos de avaliao bem como os requisitos para avaliadores lderes e avaliadores adjuntos.

Durante a descrio dos modelos, foram introduzidas duas novas nomenclaturas presentes na estrutura do MPS.BR: a Instituio Avaliadora (IA) e a Instituio Implementadora (II). A IA e II so instituies credenciadas pelo Frum de Credenciamento e Controle (FCC), a primeira a avaliadora do MPS.BR e a segunda implementadora do MR-MPS.

5.3 NVEIS DE MATURIDADE

Uma vez que a estrutura j foi apresentada, importante conhecer tambm os nveis de maturidade do MPS.BR. Os nveis vo de A at G, sendo o nvel G o mais baixo. Os nveis de maturidade estabelecem nveis de evoluo no processo de desenvolvimento de software. A partir do nvel de maturidade possvel prever o desempenho da organizao ao executar processos futuros.

14

Embora a diviso dos nveis tenha sido baseada na existente no CMMI, o MPS.BR possui graduao e classificao diferentes, pois tem como objetivo maior adoo de micro, pequenas e mdias empresas. A Figura 3 demonstra os sete nveis do MPS.BR e a respectiva correspondncia com os nveis de maturidade do CMMI.

Figura 3: Nveis do MPS.BR x Nveis do SW/CMMI

Cada nvel possui processos que indicam onde a organizao deve focar para implantar a melhoria. O alcance de nveis se deve ao atendimento de todos os resultados esperados para os respectivos nveis. No foco deste trabalho descrever detalhadamente o MPS.BR, portanto, os nveis (exceto o nvel G) no sero aqui descritos. Para maiores informaes sobre os nveis, o Guia Geral elaborado pela SOFTEX poder ser consultado. Na Tabela 2, h uma listagem de quais processos esto presentes em cada nvel.

NVEL A (Em Otimizao) B

PROCESSOS Implantao de Inovaes na Organizao (IIO) Anlise de Causas e Resolues (ARC) Desempenho do Processo Organizacional (DEP)

15

(Gerenciado Quantitativamente) C (Definido) D (Largamente Definido)

Gerncia Quantitativa do Projeto (GQP)

Anlise de Deciso e Resoluo (ADR) Gerncia de Riscos (GRI) Desenvolvimento de Requisitos (DRE) Integrao do Produto (ITP) Soluo Tcnica (STE) Validao (VAL) Verificao (VER)

E (Parcialmente Definido)

Adaptao do Processo para Gerncia do Projeto (APG) Avaliao e Melhoria do Processo Organizacional (AMP) Definio do Processo Organizacional (DFP) Treinamento (TRE)

F (Gerenciado)

Processo de Aquisio (AQU) Gerncia de Configurao (GCO) Garantia da Qualidade (GQA) Processo de Medio (MED)

Gerncia de Projetos (GPR)

(Parcialmente Gerenciado) Gerncia de Requisitos (GRE)

Tabela 2: Nveis e respectivos processos (SOFTEX, 2006)

5.3.1 NVEL G

Como iremos implantar o nvel G, ele ser descrito detalhadamente nesta seo. O nvel G o primeiro nvel de maturidade do MPS.BR. Por esse motivo, tem de ser executado com cautela. Segundo a Softex (2009), ao final da implantao a organizao ser capaz de gerenciar parcialmente seus projetos de software. A implantao do nvel G apresenta

16

dois grandes desafios para a organizao: a necessidade da mudana cultural da empresa e a redefinio do que projeto para a organizao. Faz parte do nvel G a implementao da Gerncia de Projeto e de Requisitos que sero descritas detalhadamente nas prximas sees.

5.3.1.1 GERNCIA DE PROJETOS (GPR)

O nvel G tem como propsito a definio de planos para o projeto que envolva o estabelecimento prvio de atividades, recursos e responsabilidades. Prov tambm informaes sobre o andamento do projeto e permite a alterao quando houver mudanas. como: Segundo a SOFTEX (2009), a Gerncia de Projetos pode ser definida

O processo Gerncia de Projetos (GPR) envolve vrias atividades, como: desenvolver um plano geral de controle do projeto; obter o comprometimento e mant-lo ao longo de toda a execuo do projeto; e conhecer o progresso do projeto, de maneira que aes corretivas possam ser tomadas quando a execuo do projeto desviar do planejado.

No plano de projeto esto previstos o planejamento e a execuo de monitorias no escopo, riscos, prazos e recursos. Durante o monitoramento, o plano de projeto pode ser refeito para acompanhar as mudanas do projeto. Para a fundamentao terica pode-se utilizar o PMBOK (Project Management Body of Knowledge) do PMI (Project Management Institute). O PMBOK uma guia em gerncia de projetos. Ele agrupa conhecimento e boas prticas para gerenciamento. Os resultados que devem ser atingidos com a Gerncia de projeto esto listados abaixo (SOFTEX, 2009):

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 so estimados, atravs de mtodos apropriados; GPR 3. As fases do ciclo de vida do projeto so definidas; GPR 4. A viabilidade de atingir as metas do projeto, considerando as restries e os recursos disponveis, avaliada. Se necessrio, ajustes so realizados; GPR 5. As tarefas, os recursos e a infra-estrutura necessrios para completar o trabalho so planejados; GPR 6. O cronograma e o oramento do projeto so estabelecidos e mantidos; GPR 7. Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e prioridades de tratamento so determinados e documentados; GPR 8. Os dados relevantes do projeto so identificados, coletados, armazenados e distribudos. Um mecanismo estabelecido para acess-los, incluindo (se pertinente) questes de privacidade e segurana; GPR 9. Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios para execut-lo; GPR 10. O esforo e o custo para os produtos de trabalho e tarefas so estimados baseados em dados histricos ou referncias tcnicas; 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. Revises so realizadas em marcos do projeto conforme estabelecido no planejamento; GPR 15. Registros e anlise dos problemas identificados nas monitoraes so estabelecidos; GPR 16. Aes corretivas so estabelecidas quando necessrio e gerenciadas at a sua concluso.

18

5.3.1.2 GERNCIA DE REQUISITOS (GRE)

O propsito da Gerncia de Requisitos gerenciar requisitos tanto dos produtos como dos componentes identificando e controlando inconsistncias entre os requisitos e os produtos desenvolvidos. Segundo a SOFTEX (2009), a Gerncia de Requisitos pode ser definida como:

O processo Gerncia de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais e nofuncionais, bem como os requisitos impostos ao projeto pela organizao.

O requisitos devem ser acordados entre organizao e cliente para evitar mau entendimento antes que o requisito entre no escopo do projeto. Toda mudana de requisito deve ser adequadamente documentada. Para a definio adequada de requisitos, existe a necessidade de boa comunicao entre empresa e cliente. Os requisitos tm de ser definidos e aprovados, e caso necessrio, alterados de acordo com a solicitao do cliente. Os resultados esperados com a implementao da Gerncia de Requisitos so (SOFTEX, 2009): GRE 1: Uma comunicao contnua com os fornecedores de requisitos estabelecida; GRE 2: O entendimento dos requisitos obtido; GRE 3: A aceitao dos requisitos estabelecida por meio de critrios 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: Inconsistncias entre os planos do projeto, os produtos de trabalho e os requisitos so identificadas e corrigidas; GRE 7: Mudanas nos requisitos so gerenciadas ao longo do projeto.

19

5.4 PROCESSO DE IMPLEMENTAO

O processo de implementao do MPS.BR dividido conforme a tabela abaixo:

SUBPROCESSO Contratar avaliao

ATIVIDADE Pesquisar Instituies Avaliadoras Estabelecer contrato Viabilizar a avaliao Planejar a avaliao

Preparar a realizao da avaliao

Preparar a avaliao Conduzir a avaliao inicial Completar a preparao da avaliao

Realizar a avaliao final Documentar os resultados da avaliao

Conduzir a avaliao final Avaliar a execuo do processo de avaliao Relatar resultados Registrar resultados

Tabela 3: Processo de implementao do MPS.BR (SOFTEX, 2010)

Uma empresa que deseja obter a certificao MPS.BR deve acessar o site da SOFTEX e verificar as IAs disponveis para a avaliao. A empresa deve ento solicitar sugestes de avaliao destas instituies. As IAs iro responder s solicitaes e a empresa deve ento selecionar uma IA e enviar uma reposta s outras comunicando a instituio escolhida para realizar a avaliao. A seguir, firmado um contrato entre a empresa e IA escolhida. No segundo subprocesso, a IA dar incio ao processo burocrtico que envolve: comunicar a SOFTEX, pagar taxas de servio e comunicar equipe que realizar a avaliao. A equipe de avaliao prepara o procedimento que abrange enviar um molde de avaliao para a organizao contendo o projeto e o cronograma. Planilhas so preenchidas e uma avaliao inicial realizada a partir dos dados fornecidos. A partir da, a implementao e avaliao se inicia.

20

6. ESTUDOS DE CASO

Dois estudos de caso foram realizados. O grupo pesquisou empresas que j possuem ou almejam o nvel G da certificao 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 Municpio de Belo Horizonte (PRODABEL).

6.1 ESTUDO DE CASO - ICODES

No artigo Processo de Desenvolvimento de Software em Conformidade com o Nvel G do Modelo de Referncia MPS.BR, Lehrer (2007) descreve a implementao do nvel 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 - Gois. Foi criado no primeiro trimestre de 2006 com uma equipe tcnica que contava com cinco colaboradores, e na poca que o artigo foi escrito, a empresa estava com nove colaboradores (LEHRER, 2007). O objetivo da implantao alcanar processos mais maduros que equilibrem qualidade com produtividade. Alm disso, a certificao equipararia o instituto com outros institutos ou empresas nacionais e internacionais na produo de software de qualidade. O autor relata ento os esforos realizados para implantar a Gerncia de Projetos e a Gerncia de Requisitos. Tal implantao teve um esforo de quinhentas horas. Para a implantao da Gerncia de Projetos, o instituto adotou o uso do Plano de Projeto para todos os projetos do ICODES. Neste documento, criado no incio 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

indicando reunies e tcnicas e de qualidade. A empresa adotou o uso da ata em toda reunio realizada. Durante o acompanhamento, o plano de projeto ir conter todos os monitoramentos necessrios como: cronograma, custos, riscos, contrataes 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 Gerncia de Requisitos, o instituto ir realizar reunies com os clientes at que os requisitos fiquem claros para ambas as partes. As reunies sero realizadas com clientes e potenciais usurios do sistema. Antes das reunies, os membros do ICODES j definiro quais os questionamentos que devero ser abordados. Aps cada reunio, um relatrio ser elaborado e dever ser aprovado pelo cliente. Este processo

22

ser realizado at que os requisitos estejam claros. Havendo algum requisito dbio, os colaboradores do instituto devero esclarec-lo com o cliente. Aps isso, elaborado o documentos de requisitos, cujo ndice esta na Figura 5:

Figura 5: ndice do documento de requisitos (LEHRER, 2007)

Lehrer (2007) descreve ento algumas dificuldades encontradas. A primeira foi a barreira que os colaboradores colocaram na necessidade de realizar documentao de todas as reunies. A segunda, a dificuldade que os gerentes de projetos tiveram ao realizar o Plano de Projeto logo no incio do projeto. Os colaboradores chegaram at

23

mesmo a questionar o real benefcio da adoo do programa. Tais dificuldades foram vencidas com o tempo atravs de conversas informais e demonstraes dos benefcios da implantao do MPS.BR. At a escrita do artigo, o ICODES no havia realizado a avaliao, estava somente se preparando. O instituto pretendia com a certificao alcanar melhoria no processo de desenvolvimento e, conseqentemente, aumentar a qualidade e produtividade de software.

6.2 ESTUDO DE CASO - PRODABEL

O artigo Diagnstico da Implantao da MPS.BR Nvel G na Administrao Pblica: Estudo de Caso na Prodabel, Souza et al (2008) descreve a implementao do nvel G na PRODABEL. A empresa Processamento de Dados do Municpio de Belo Horizonte (PRODABEL) responsvel por toda a gesto de tecnologia da informao da prefeitura municipal de Belo Horizonte. Presta servios de desenvolvimento e manuteno de software, alm de toda a infra-estrutura tecnolgica. Atualmente, a empresa possui aplicaes standalone, cliente-servidor e web. A equipe composta de 480 colaboradores, sendo 130 de desenvolvimento de sistemas, e est distribuda por todo o municpio (unidades setoriais) (SOUZA et al, 2008). So desenvolvidos e mantidos aproximadamente 200 sistemas com tecnologias variadas. Alm destes sistemas, h 50 projetos em andamento. So fatores que dificultam a padronizao e qualidade no desenvolvimento de software: os diferentes nveis de capacitao, a descentralizao das equipes de trabalho e, o grande volume de aquisio de servios e produtos. As contrataes de servios podem compreender somente testes, todo o desenvolvimento do sistema e ainda a aquisio de pacotes prontos. A conseqncia de todos esses fatores foi a dificuldade de gerenciamento, prejudicando o custo, prazo, qualidade, e a falta de previsibilidade no desenvolvimento

24

de sistemas feitos tanto pela equipe quanto por contratao 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 durao de 15 meses e foi organizado para atender os processos de Gerncia de Requisitos (GRE) e Gerncia de Projetos (GPR) da MPS.BR. O escopo do projeto dividiu-se em quatro etapas:

ETAPAS Diagnstico inicial

DESCRIO Entrevistas, relatrio e treinamento.

Definio do processo Descrio 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 definies do processo Avaliao Anlise crtica, pr-avaliao e avaliao oficial do MPS.BR.
Tabela 4: Escopo do projeto Mps-Pdbl

As reunies com a equipe ocorreram semanalmente e com a Instituio Implementadora, quinzenalmente. Nessas reunies, foram avaliadas a implementao do projeto de melhoria, o andamento dos trabalhos, a adequao das solues implementadas e a aderncia do processo ao modelo. O maior problema encontrado foi que alguns membros sentiam-se perdidos no processo, pois no tinham conhecimento de conceitos fundamentais, como por exemplo, ciclo de vida de um projeto. Lies aprendidas: Necessidade de tratar melhor as diferenas de competncia dos membros da equipe, respeitando a capacidade de cada um. Necessidade de treinamento em processo de software. 80 funcionrios foram capacitados em cursos de Introduo ao processo de software, requisitos e anlise. O consenso das decises da equipe precisa ser mais gil.

25

A melhor forma de se avaliar os resultados a execuo do processo em um projeto-piloto. No aceitar comportamentos do tipo no conheo e no gostei.

A PRODABEL foi a primeira empresa municipal de servios de informtica e a segunda empresa no Brasil certificada no MPS.BR, nvel G. A avaliao foi feita em junho de 2008.

7.

IMPLEMENTAO

NA

DIRETORIA

GERAL

DE

RECURSOS

HUMANOS (DGRH)

Pretende-se preparar a equipe de desenvolvimento de sistemas para a implantao do programa MPS.BR nvel G. Para isso apresentaremos uma breve descrio da equipe, a abordagem IDEAL que ser utilizada e os esforos realizados para a Gerncia de Projetos e Requisitos (processos que so focos do nvel G). Vale ressaltar que, por ora, no haver certificao, a equipe vai somente desenvolver estratgias para a implementao. Caso a gerncia aceite realizar a certificao ter de ser feito um processo de licitao para uma instituio avaliadora. Portanto, a presente monografia ir descrever somente o que fazer para implantar o nvel G.

7.1 A EQUIPE DE INFORMTICA DA DGRH

A Diretoria Geral de Recursos Humanos (DGRH) a unidade que gerencia, planeja e executa as polticas de recursos humanos da Universidade Estadual de Campinas (UNICAMP). A equipe de informtica dividida em clulas conforme figura:

26

Figura 6: Organograma da Equipe de Informtica da DGRH

A DGRH utiliza alguns mdulos de um pacote comprado da empresa Senior Sistemas, uma empresa de Blumenau Santa Catarina. O pacote, denominado Vetorh, composto por vrios mdulos totalmente integrados. Apesar do aplicativo ser um produto fornecido por terceiros, a equipe de desenvolvimento da DGRH/Informtica possui independncia para manuteno dos mdulos do sistema, podendo fazer alteraes, como gerar relatrios e telas de consultas e cadastros, assim como implementaes 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. Alm deste pacote, a equipe possui alguns sistemas WEB desenvolvidos em JAVA. Estes sistemas so desenvolvidos quando o projeto especfico da universidade e o pacote no atende. A implantao ir atingir a Clula Java e a Clula Vetorh por se tratarem das nicas que desenvolvem softwares.

27

7.2 OBJETIVOS DA IMPLANTAO

A equipe de informtica da DGRH no segue nenhum padro de processo de desenvolvimento de software e no possui nenhuma certificao. Por este motivo, os projetos acabam ficando mal documentados, mal gerenciados e suscetveis de falhas. A Figura 6 contm os problemas que a DGRH encontra e os benefcios que a implantao do MPB.BR ir trazer nos projetos da equipe.

Figura 7: Problemas x Expectativas

Espera-se que com a implantao do MPS.BR e em particular do nvel G, a gerncia tenha maior controle sobre o projeto e os requisitos sejam controlados de forma adequada. Tal meta s ser possvel com a motivao de toda equipe, esta meta pretende ser alcanada atravs de reunies onde sero expostos os benefcios da implantao de um programa de melhoria.

28

7.3 ABORDAGEM IDEAL

A abordagem IDEAL ser usada como facilitadora da implementao do nvel G do MPS.BR na Equipe de informtica da DGRH. De acordo com Corsoguinho (2006) a abordagem IDEAL :
Elaborado pelo Software Engineering Institute (SEI), o IDEAL uma abordagem que apresenta aes de iniciao, planejamento e execuo de melhorias organizacionais. Prope uma infra-estrutura para guiar as empresas no planejamento e implantao efetivos de um programa de melhoria, seja na implantao de uma nova ferramenta ou na definio de processos para todo o ciclo de vida dos projetos.

A abordagem dividida em cinco fases que foram adaptadas a nossa realidade do MPS.BR: I Initiating: na iniciao tem de ser feito um levantamento das expectativas relacionadas ao MPS.BR, necessrio verificar se as expectativas esto alinhadas com os projetos da empresa. Neste momento que se firma o compromisso com os patrocinadores que iro garantir a infra-estrutura necessria para a implantao; D Diagnosing: nesta fase, faz-se um estudo de quais problemas da empresa a implementao do MPS.BR ir resolver. feito um diagnstico da maturidade do processo de desenvolvimento de software da empresa. E Establishing: no planejamento, definida a estrutura e sequenciamento das atividades que sero realizadas. Atravs do diagnstico realizado anteriormente, possvel definir com mais clareza que problemas sero resolvidos com a implantao do MPS.BR;

A Acting: nesta fase, as pessoas selecionadas de cada time realizam as aes e as melhorias previstas so implementadas; L Learning: nesta fase, os membros se renem para discutir a implantao e registram pontos positivos e negativos para dar suporte aos prximos projetos.

As fases de iniciao e diagnstico esto descritas na seo anterior. E as fases de planejamento e execuo sero descritas nas sees a seguir.

29

7.4 IMPLANTAO DA GERNCA DE PROJETOS (GPR)

O nvel G trata da Gerncia de Projetos que, como definido acima, tem por objetivo o controle de todo o projeto do incio ao fim. No primeiro semestre de 2010, o grupo realizou a disciplina FT027 Gesto e Qualidade de Projetos. Durante a disciplina, o professor Dr. Marcos Borges solicitou que os alunos desenvolvessem um trabalho de gerncia de projetos prtico. Foi realizada ento a gerncia de projetos no projeto Avaliao Institucional da Unicamp, que estava sob responsabilidade da clula Java da Equipe de Informtica da DGRH. Durante a disciplina, o professor deu as coordenadas de como gerenciar um projeto usando o guia PMBOK e os alunos aplicaram os ensinamentos em seus projetos. O projeto Avaliao foi gerenciado e documentado de acordo com as normas do PMBOK. Para a implantao da gerncia de projetos na DGRH sero utilizadas as lies aprendidas neste projeto. Todos os projetos que iro ser realizados pela DGRH tero de ser gerenciados e seguir o que foi feito no projeto Avaliao. Durante os outros projetos, pretende-se estabelecer um ritmo de melhoria contnua que deve ser devidamente documentado e disseminado aos membros do grupo. O Plano de Projeto dever ser feito para todos os projetos e dever ter os seguintes itens:

Charter (Incio):
Descrio do Projeto Propsitos Objetivos Escopo Escopo No Escopo Stakeholders Cronograma Macro Custos previstos Anlise de riscos inicial

30

Planejamento:
WBS Seqenciamento de atividades Cronograma Macro Gerenciamento Custos Gerenciamento de Riscos Identificao dos riscos Anlise qualitativa dos riscos Anlise quantitativa dos riscos Plano de mitigao de riscos Gerenciamento de Qualidade Planejamento de contrataes Planejamento de compras

Execuo:
Gerenciamento das entregas (prottipos) Gerenciamento da qualidade Gerenciamento das mudanas

Monitoramento:
Verificao do escopo Controle do escopo Controle de cronograma Controle de custo Controle de qualidade Gesto do Time Relatrios de desempenho Gesto de stakeholders Monitorar e controlar riscos Administrao de contratos

Encerramento:
Encerrar o Projeto.

A criao do charter e do plano de projeto necessita ser realizada no incio do projeto e dever ser replanejado de acordo com as mudanas que acontecero no projeto. Em relao ao acompanhamento, sero realizadas reunies semanais que tero por objetivo verificar o estado dos projetos, acompanhar se o andamento esta de acordo com o previsto, e caso no esteja, o gerente dever tomar as medidas cabveis. Em cada reunio, atas devero ser produzidas e enviadas aos participantes para aprovao.

31

7.5 IMPLANTAO DA GERNCIA DE REQUISITOS (GRE)

O nvel G ir tratar tambm da Gerncia de Requisitos que tem por objetivo o controle adequado dos requisitos e das mudanas que podem acontecer. Para gerenciar os requisitos, ser necessrio que a equipe tenha um contato direto e sadio com as diretorias que requisitam os servios. Os requisitos devem estar completamente claros para a equipe e o cliente tem de estar de acordo com o estabelecido. Os requisitos devero ser extrados atravs de uma reunio de brainstorm (onde todos do idias, sem medo, para o projeto). A equipe ir ento documentar a reunio e refinar os requisitos com o cliente. importante que os membros participantes da reunio j saibam o que falar e solicitar antes da mesma, para que o cliente no seja prejudicado com a questo de tempo. Com os requisitos fechados, o projeto pode comear a ser desenvolvido. Porm, comum que as diretorias solicitem mudanas para a equipe de informtica. Estas mudanas tero de ser documentadas e uma linha histrica dever ser mantida. As diretorias solicitantes tm de saber que mudanas durante o desenvolvimento so prejudiciais e, por isso, devem ser evitadas. S podem ocorrer se bem planejadas. Os documentos que dar suporte Gerncia de Requisitos tero os seguintes tpicos:

Documento de Requisitos:
Requisitos Lista de Requisitos Funcionais Lista de Requisitos No Funcionais Produo de Requisitos Levantamento (Reunio de Brainstorm) Registro Gerenciamento de Requisitos Identificar Mudanas de Requisitos Avaliar Impactos Documentar Mudanas de Requisitos

32

Aprovao das Mudanas e Replanejamento do Projeto

7.6 DIFICULDADES ENCONTRADAS

Uma dificuldade prevista a imposio de novas regras para os membros que tero de ser persuadidos que o programa trar muitos benefcios equipe. Alguns treinamentos sero necessrios para que a equipe se adeque as gerncias do nvel G. Outra dificuldade a necessidade de recursos financeiros, com o estudo dos casos e essa preparao para a implantao do nvel G pretende-se persuadir a gerncia da necessidade da implantao de um processo de melhoria da qualidade do software. E que o melhor processo o MPS.BR, pois, usado em pequenas e mdias empresas. Sabemos que a UNICAMP uma universidade pblica grande, mas a implantao desse processo tem como objetivo somente a equipe de informtica da DGRH.

33

8. CONCLUSO

O grupo objetivava estudar o MPS.BR e realizar uma estratgia de implantao das Gerncias de Requisitos e Projetos (Nvel G) na Equipe de Informtica da DGRH. Para dar apoio implantao, foram selecionados dois estudos de caso das empresas ICODES e Prodabel. Os estudos de casos ajudaram o grupo a montar uma estratgia mais concisa e realista. Na definio do que seria realizado para implantao, o grupo focou na documentao necessria para ambas as gerncias. Foi verificado que importante que a equipe esteja preparada antes de contactar a Instituio Avaliadora. Foram fundamentais os estudos realizados na disciplina FT027 para a Gerncia de Projetos. Em relao Gerncia de Requisitos, foram aplicados os conhecimentos de Engenharia de Software. A certificao da equipe de Informtica no tem pretenso de atingir mais clientes, pois a UNICAMP uma empresa pblica. A certificao tem por objetivo ajudar a equipe a produzir software de melhor qualidade que atendam s necessidades das diretorias solicitantes. O MPS.BR foi escolhido porque de fcil acesso e tem custo e prazo de implantao reduzido. Conclumos que, a qualidade um pr-requisito importante para toda a produo de software e as empresas h algum tempo j tiveram essa percepo. Os dois estudos de caso mostraram que o MPS.BR ajudou na evoluo da qualidade do processo e no apresenta barreiras para implantao como os demais padres internacionais. Na equipe de Informtica da DGRH a implantao, se futuramente aprovada, trar inmeros benefcios em relao ao controle dos processos e ademais, a satisfao dos clientes.

34

REFERNCIAS
CORSOGUINHO, C.C. Como Iniciar e Acompanhar um Programa de Implantao do MPS.BR. ProQualiti Qualidade na Produo de Software. v.2, n.2. Minas Gerai, Brasil, 2006.

CORTS, M. L., CHIOSSI, T. C. S. Modelos de qualidade de software. UNICAMP, 2001.

KOSCIANSKI, A., Soares, M. S. Qualidade de Software. Novatec, Segunda Edio, 2007.

LEHRER, C. Processo de desenvolvimento de software em Conformidade com m Nvel G do Modelo de Referncia MPS.BR. Instituto Centro-Oeste de Desenvolvimento de Software ICODES. Gois, Brasil. 2007.

PRESSMAN, R. S. Engenharia de software. McGraw Hill, 2002.

SOFTEX - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral, verso 1.1. Maio, 2006. SOFTEX ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS. Setembro de 2009.

SOMMERVILLE, I. Engenharia de software. Pearson Education, Oitava Edio, 2007. SOUZA, J, P; PINTO, M, V. Diagnstico da Implantao da MPS.BR Nvel G na Administrao Pblica: Estudo de Caso na Prodabel. Belo Horizonte, Minas Gerais, Brasil. 2008.