UNIVERSIDADE FEDERAL DO PAR CENTRO DE CINCIAS EXATAS E NATURAIS DEPARTAMENTO DE INFORMTICA CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Ricardo Carvalho de Souza

GERNCIA DE PROJETOS DE SOFTWARE UM ESTUDO DE CASO: PMBOK(PMI) e RUP

Belm 2005

UNIVERSIDADE FEDERAL DO PAR CENTRO DE CINCIAS EXATAS E NATURAIS DEPARTAMENTO DE INFORMTICA CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Ricardo Carvalho de Souza

GERNCIA DE PROJETOS DE SOFTWARE UM ESTUDO DE CASO: PMBOK(PMI) e RUP

Trabalho de Concluso de Curso apresentado para

obteno do grau de Bacharel em Cincia da Computao. Orientador: Prof. Fabrcio da Cunha Rodrigues

Belm 2005

UNIVERSIDADE FEDERAL DO PAR CENTRO DE CINCIAS EXATAS E NATURAIS DEPARTAMENTO DE INFORMTICA CURSO DE BACHARELADO EM CINCIA DA COMPUTAO

Ricardo Carvalho de Souza GERNCIA DE PROJETOS DE SOFTWARE UM ESTUDO DE CASO: PMBOK(PMI) e RUP
Trabalho de Concluso de Curso apresentado para obteno do grau de Bacharel em Cincia da Computao

Data da defesa: 04 de Fevereiro de 2005 Conceito: Excelente Banca Examinadora

Prof. Fabrcio da Cunha Rodrigues Universidade Federal do Par Orientador

Profa. Cibelle Simone Alves do Nascimento Universidade Federal do Par Membro

Prof. Osiel Marlon Negro da Silva Universidade Federal do Par Membro

Belm 2005

A Deus, a minha famlia, a minha namorada, aos meus amigos e a todos aqueles que tambm acreditam em mim.

AGRADECIMENTOS

A minha me, meu pai e minhas duas irms, por tudo. Amo vocs. A Vernica Souza Leal Rocha Saliba e toda sua famlia, por confiarem e me apoiarem na realizao dos meus sonhos. Aos meus grandes e verdadeiros Amigos, pelas sinceridades e amizades, contribuindo para a fomentao de f e esperana. Ao Professor e Amigo Fabrcio Rodrigues, por aceitar o desafio da orientao no desenvolvimento deste trabalho, acreditando no meu potencial. Ao Professor Mestre Ricardo Viana Vargas, ao Wagner Maxsen e ao Giovanni Giazzon dos Santos, todos do Grupo A&C, pelas prestigiosas ajudas realizadas, provendo-me o direcionamento necessrio para os meus esforos. Ao Gerente de Desenvolvimento de Software da SERPRO-PA, Sr. Ticiano Monteiro, por prestar tempo e ateno necessrios para a realizao do Estudo de Caso. Aos profissionais competentes e prestativos, formadores de importantes listas de discusso, que colaboram para as pesquisas e progressos realizados em diversas reas do conhecimento.

"Pense como uma pessoa de ao e aja como uma pessoa que pensa." Henri Louis Bergson.

SUMRIO p. LISTA DE FIGURAS............................................................................................... RESUMO................................................................................................................... ABSTRACT............................................................................................................... 1 INTRODUO...................................................................................................... 2 GERNCIA DE PROJETOS............................................................................... 2.1 FUNDAMENTOS............................................................................................... 2.2 CONTEXTO....................................................................................................... 2.3 PROCESSOS...................................................................................................... 2.4 REAS................................................................................................................ 2.4.1 Integrao.......................................................................................................... 2.4.2 Escopo............................................................................................................... 2.4.3 Prazo.................................................................................................................. 2.4.4 Custo.................................................................................................................. 2.4.5 Qualidade........................................................................................................... 2.4.6 Recursos Humanos............................................................................................ 2.4.7 Comunicaes.................................................................................................... 2.4.8 Riscos................................................................................................................ 2.4.9 Aquisies......................................................................................................... 3 PROCESSO DE SOFTWARE............................................................................. 3.1 FUNDAMENTOS............................................................................................... 3.2 MELHORES PRTICAS................................................................................. 3.2.1 Interatividade..................................................................................................... 3.2.2 Gerncia de Requisitos...................................................................................... 3.2.3 Arquitetura baseada em Componentes.............................................................. 3.2.4 Modelagem Visual............................................................................................. 3.2.5 Controle de Qualidade....................................................................................... 3.2.6 Controle de Mudanas....................................................................................... 8 9 10 11 13 13 16 19 23 24 25 26 28 28 30 30 32 33 35 35 39 39 40 41 42 42 43

4 GERNCIA DE PROJETOS DE SOFTWARE: PMBOK e RUP.................... 44 4.1 CONSIDERAOES INICIAIS......................................................................... 4.2 RELACIONANDO O PMBOK E RUP............................................................ 44 45

4.3 MAPEAMENTO ENTRE REAS E ATIVIDADES..................................... 2.3.1 Processos de Gerncia de Integrao................................................................ 2.3.2 Processos de Gerncia de Escopo...................................................................... 2.3.3 Processos de Gerncia de Prazo........................................................................ 2.3.4 Processos de Gerncia de Custo........................................................................ 2.3.5 Processos de Gerncia de Qualidade................................................................. 2.3.6 Processos de Gerncia de Recursos Humanos.................................................. 2.3.7 Processos de Gerncia de Comunicaes.......................................................... 2.3.8 Processos de Gerncia de Riscos....................................................................... 2.3.9 Processos de Gerncia de Aquisies................................................................ 5 QUALIDADE DE SOFTWARE.......................................................................... 5.1 FUNDAMENTOS...............................................................................................

46 49 53 55 55 56 57 57 58 59 61 61

5.2 QUALIDADE DE SOFTWARE........................................................................ 62 5.3 QUALIDADE DE SOFTWARE COM PMBOK E RUP................................ 6 ESTUDO DE CASO: SERPRO-PA.................................................................... 6.1 CONSIDERAES INICIAIS......................................................................... 6.2 ANLISE DE DADOS...................................................................................... 64 66 66 67

6.3 RESULTADOS DA PESQUISA........................................................................ 68 7 CONCLUSO....................................................................................................... REFERNCIAS BIBLIOGRFICAS................................................................... ANEXOS................................................................................................................... 69 71 74

LISTA DE FIGURAS Figura 1. Relacionamento entre outras disciplinas......................................................... 16 Figura 2. Exemplo genrico de ciclo de vida de um projeto.......................................... Figura 3. Relacionamento entre o ciclo de vida do produto e do projeto..................... Figura 4. Principais variveis de um projeto.................................................................. Figura 5. Relacionamento simplificado entre grupo de processos................................ Figura 6. Sobreposio de atividades............................................................................... Figura 7. Processamento do ciclo de vida........................................................................ Figura 8. Dimenses do RUP............................................................................................ Figura 9. Ligao entre o PMBOK e o RUP atravs da Gerncia de Projetos-RUP.. Figura 10. Mapeamento dos processos de Integrao com Disciplinas do RUP.......... Figura 11. Mapeamento dos processos de Escopo com Disciplinas do RUP................ Figura 12. Mapeamento dos processos de Prazo com Disciplinas do RUP.................. Figura 13. Mapeamento dos processos de Custo com Disciplinas do RUP.................. Figura 14. Mapeamento dos processos de Qualidade com Disciplinas do RUP.......... Figura 15. Mapaeamento dos processos de Recurso Humanos com Disciplinas do RUP..................................................................................................................................... Figura 16. Mapeamento dos processos de Comunicao com Disciplinas do RUP..... 57 58 17 18 20 21 22 23 37 47 50 54 55 56 56

Figura 17. Mapeamento dos processos de Riscos com Disciplinas do RUP.................. 59 Figura 18. Mapeamento dos processos de Aquisies com Disciplinas do RUP.......... Figura 19. Nveis do CMM................................................................................................ Figura 20. Qualidade mapeada na integrao do PMBOK e RUP............................... 60 63 65

RESUMO

Este trabalho ter como objeto de estudo a combinao dos conceitos e metodologias estudados pelo PMI1 disponibilizados no PMBOK2 com o RUP3, como forma de concretizar a viabilizao de um caminho para se alcanarem objetivos dentro de uma empresa/instituio de desenvolvimento de software em termos de qualidade. Apresenta uma breve discusso sobre a Qualidade de Software obtida, seja no seu processo submetido, seja no produto final, ressaltando o CMM4 e o CMMI5. O trabalho tambm realiza um estudo de caso, elaborado sob os domnios do SERPRO-PA(Servio Federal de Processamento de Dados Sede Par),

cujo tenta compreender a realidade coorporativa desta empresa e relacion-la com os conceitos abordados no trabalho.

PALAVRAS-CHAVES: Gerncia de Projetos, Processo de Software, Qualidade em Software, Gerncia de Projetos de Software, PMI, PMBOK, RUP, CMM, CMMI.

1 2

PMI Project Management Institute. www.pmi.org. PMBOK Project Management Body of Knowledge. 3 Edio. 2004. PMI. 3 RUP Rational Unified Process. Processo Unificado. www.rational.com. IBM. 4 CMM Capability Maturity Model. www.sei.cmu.edu. Software Enginnering Institute. 5 CMMI - Capability Maturity Model Integration. www.sei.cmu.edu. Software Enginnering Institute.

10

ABSTRACT

This work will have as object-study the combination of concepts and methodologies studied by PMI that are available in PMBOK with RUP, like a way to obtain a path to achieve qualities objectives inside software development enterprise/institute. It presents a brief discussion about Software Quality acquired in the submitted process and in a delivered product, principally the standards CMM and CMMI. The work also has a case study, elaborated over SERPRO-PA ( Servio Federal de Processamento de Dados- Sede Par ) domain, that attempts to comprehend its corporate reality and combine it with all exhibit concepts within this research.

KEY WORDS: Project Management, Software Process, Software Quality, Software Project Management, PMI, PMBOK, RUP, CMM, CMMI.

11

1.

INTRODUO

Durante anos, o desenvolvimento de sistemas vem evoluindo e progredindo no sentido de se tornar gerencivel. Historicamente, nas dcadas de 1950 e 1960, os sistemas eram muito simples e considerados ad-hoc 6, com o passar de algumas dcadas, proporcionados com o avano do aparato tecnolgico, as necessidades passaram a ser mais complexas e com isso sistemas tornaram-se mais robustos. At ento, o que se tinha em termo de Tecnologia de Informao para prover certa garantia de qualidade, dentre outros requisitos importantes, eram tcnicas como fluxogramas, diagrama de mdulos postergados pela programao estruturada, projeto estruturado e anlise estruturada. Mediante tal avano considerado para a Engenharia de Software, o desenvolvimento de sistema passou a atingir nveis de produo cada vez maiores, atribudos a sua grande demanda de mercado. Desde ento, as grandes corporaes j haviam percebido a fundamental importncia dos sistemas informatizados para todo o processo de negcio, independentemente de sua rea de conhecimento e atuao. Neste contexto todo, j se arquitetava metodologias para gerenciar projetos de desenvolvimento de software devido s necessidades evidentes de se planejar e controlar as atividades em todo o processo agregado no software e s perspectivas de atender novos requisitos, por sua vez mais complexos. Assim, para um nvel de produo maior, foram formulados novos paradigmas, como a Anlise Orientada a Objetos com base em resultados interessantes e concretos, sendo que este veio atingir um grande nvel de maturidade j na dcada de 1990, quando somado com conceitos de padres de projeto, frameworks
7

componentes de software, acabaram por prover um suporte confivel e robusto para que o processo de desenvolvimento de sistemas pudesse atingir grandes objetivos e resolver grandes problemas, sejam eles funcionais ou no. A UML8 surgiu com uma proposta interessante para toda a cadeia de produo de sistema, seu objetivo era, e continua sendo, de ser uma linguagem padro de notaes, diagramas e formas de representao dentre as at ento existentes e distintas entre pessoas e organizaes. O simples fato de o mercado adotar essa notao como padro j significava enormes passos para o gerenciamento de projetos de software. Devido a essencial importncia e influncia de tornar um processo de negcio informatizado para uma empresa, diminuir o

6 7

ad-hoc, referente a estgio inicial, para um determinado e simples ato. framewoks, prov uma soluo para uma famlia de problemas semelhantes. 8 UML Unified Modeling Language. Linguagem de Modelagem Unificada. www.rational.com. IBM.

12

gap

entre administradores e gerentes de projeto de software se mostrou necessrio e vital.

Portanto, para ambas as partes, percebeu-se que era importante gerir custos, recursos, tempo e qualidade, entre inmeros outros fatores. A obteno de melhores resultados em conforme com as necessidades veio conjuntamente com o advento do RUP, que apoiado principalmente pela UML, formalizou e criou uma metodologia para gerir o processo de desenvolvimento de software. E com isso, novos conceitos relativos qualidade e eficincia comearam a fazer parte do cotidiano. No estgio atual e natural de uma evoluo, surgiu ento a real necessidade do conceito de Gerncia de Projeto de Software, onde o processo de desenvolvimento em si passaria a dar um suporte muito importante para um processo maior, encadeado por metas e objetivos da corporao. Com isso, a Tecnologia de Informao passa a se atrelar mais com a prpria administrao da empresa e esse relacionamento acabaram ganhando significativa importncia, com intuito de enriquecer este ponto e criar esse elo, metodologias de gerncia de projetos, como PMBOK, passou a ter forte influncia no desejo de tornar a gerncia de projetos de software algo completo. Portanto, este trabalho, visa mostrar tal elo entre a Gerncia de Projetos e o Processo de Software, abordando tcnicas, metodologias e ferramentas, alm de citar pontos relevantes para os assuntos envolvidos, como a qualidade. Um estudo de caso ser apresentado utilizando-se de PMBOK com RUP como base, provendo um melhor entendimento da forte relao entre tais conceitos.

gap, referente a distncia, espao intercalado.

13

2.

GERNCIA DE PROJETOS

2.1

Fundamentos

Nas ltimas dcadas do sculo passado (XIX), o mundo dos negcios j se mostrava complexo o suficiente para exigir alguma disciplina til para seus processos. As primeiras iniciativas surgiram dentro de governos e empresas bem organizados e tiveram grande influncia dos assuntos abordados pela teoria da Administrao Geral. No incio do sculo XX, Frederick Taylor e Henry Gannt proveram importantes conceitos para o mundo dos negcios, j mais exigente, contribuindo para a cincia de gerenciar projetos. J em meados da dcada de 60, muitas metodologias, tcnicas e ferramentas passaram a ter reconhecimento dentre os assuntos at ento estudados, devido principalmente a crescente complexidade dos projetos e exigncias mercadolgicas. Comeava-se ento a normalizar e aglomerar conhecimentos importantes para o alcance de eficcia e qualidade nos projetos, independente de sua natureza, o que resultou na criao da disciplina Gerncia de Projetos. Neste estgio inicial, sua aplicabilidade era visvel na indstria blica e aeroespacial norte-americana (ex: NASA, NAVY e ARMY), seguida pela Engenharia, principalmente a Civil. Surgiu ento o PMI como pioneiro na regulao e distribuio de todo conhecimento at ento estudado para esta disciplina e vem organizando-o durante todos esses anos atravs do PMBOK, um guia padronizado para a orientao em prticas do gerenciamento de projetos. Atualmente, mediante a necessidade de se concretizar um determinado plano de negcio dentro de uma organizao, tem-se como meio a criao de projetos. Um projeto comumente compreendido como uma atividade, ou conjunto de atividades, executada por pessoas, com restries de recursos e sendo planejadas, executadas e controladas. Em relao aos modelos antigos,
A estrutura da maioria das empresas burocrtica e lenta e esses modelos no conseguem dar uma resposta rpida a um ambiente em constante mutao. Portanto a estrutura tradicional deve ser substituda por uma estrutura de projetos que seja capaz de responder rapidamente s situaes criadas dentro e fora das organizaes (Kerzner,2001).

14

Pelo motivo de um projeto depender de diversos parmetros, a criao deste empreendimento tem caractersticas prprias, so temporrios e comumente possui um fator intrnseco de unicidade do esforo global do trabalho do projeto, apesar da presena de fatores repetitivos (Objetivo nico). A questo de tempo tem como referncia um escopo temporal com incio e fim muito bem definidos e no representando esforos continuados. Vale ressaltar que a questo temporal no se aplica necessariamente ao produto ou servio criado pelo projeto. O fim de um projeto normalmente marcado pelo sucesso nos objetivos propostos, diferenciando dos servios continuados que acabam por criar novos objetivos medida que vo sendo alcanados. Esta natureza temporal tambm transparece devido s oportunidades ou nichos de mercado que so temporrios. A concepo dessas duas caractersticas so fatores que influenciam metodologias, mtodos e at ferramentas que auxiliam no planejamento de atividades em um projeto. Da integrao dos conceitos de temporrio e nico, surge outra caracterstica interessante: a Elaborao Progressiva. Como o escopo temporal determinado e o produto ou servio nico, as peculiaridades/especialidades deveram ser elaboradas

progressivamente, em etapas, em um processo incremental, gerando artefatos mais bem detalhados. Assim, a equipe adquire melhor percepo do produto ou servio. Esta elaborao deve levar em considerao muitos fatores do projeto, principalmente o escopo do projeto, que sero discutidos mais adiante. Geralmente, um projeto criado no intuito de se prover a realizao de algum requisito diferente do cotidiano operacional (operaes permanentes e repetitivas) da organizao, podendo ser instanciados em qualquer setor e envolver recursos dos mais variados possveis. Dependendo das estratgias das empresas, determinado projeto pode ter fundamental importncia para o ciclo de vida desta, portanto, dominar os parmetros necessrios para a concretizao de um projeto, visando qualidade e eficincia de extrema importncia, principalmente no contexto competitivo do mercado atual. Mesmo com muitas discusses sobre o que gerenciar, quem gerenciar e como gerenciar, uma maneira simples de se definir :

Gerenciar consiste em executar atividades e tarefas que tm como propsito planejar e controlar atividades de outras pessoas para atingir objetivos que no podem ser alcanados caso as pessoas atuem por conta prpria (Koontz & O Donnel,1980).

15

O gerenciamento do projeto normalmente acompanhado por uso de processos bem definidos, tais como: iniciao, planejamento, execuo, controle e encerramento e envolve as demandas concorrentes (tempo, escopo, risco, etc.), comprometimento das partes envolvidas e uma eficaz identificao dos requisitos. Muitos desses processos so naturalmente interativos e as interaes provem aperfeioamento do produto ou servio e um maior conhecimento acerca destes, aumentando a capacidade de gerenci-los, em referncia elaborao progressiva. A gerncia de projetos estruturada basicamente em um contexto e seus processos. O contexto tem o foco no ambiente que o projeto foi instanciado, j os processos, tm o foco no clico de vida do produto ou servio. Os processos atuam em nove reas de conhecimento ou disciplinas, so elas: 1. Integrao; 2. Escopo; 3. Tempo; 4. Custo; 5. Qualidade; 6. Recursos Humanos; 7. Comunicaes; 8. Riscos; e 9. Aquisies. Essas reas, devido seus altos nveis de abrangncia, foram subdivididas em 29(vinte e nove) subreas, para fornecer melhor organizao a Gerncia de projetos. Tanto a estrutura quanto essas reas, sero discutidas em detalhes mais adiante. Antes de se discutir em mais detalhes os processos e as suas nove reas de atuao, importante frisar o complexo e robusto universo de conhecimentos da Gerncia de Projetos. Quando pensadas e estudadas, as nove reas delimitadas surgiram com o intuito de atender a necessidade de uma vasta gama de problemas e relacionar de uma forma harmnica conceitos de projetos de diversas reas de aplicao. Estas reas de aplicao possuem suas peculiaridades de projetos, que apesar de ter alguns elementos comuns com outras reas de aplicao, caracteriza a rea em questo e a torna exclusiva. A Figura 1 ilustra este relacionamento com outras disciplinas e onde o PMBOK encontra-se.

16

Universo de Conhecimentos da Gerncia de Projetos Conhecimentos e prticas da Gerncia de Projetos geralmente aceitas PMBOK Guide

Conhecimentos e habilidades da Gerncia Geral Habilidades interpessoais

Conhecimentos, modelos e regras da rea de Aplicao Compreenso do Ambiente do Projeto

Figura 1. Relacionamento entre outras disciplinas. (Fonte: Adaptao PMBOK, 3th, 2004).

2.2

Contexto

Segundo o PMBOK(2004), compreender o contexto da gerncia de projetos prover a capacidade de gerenciar um ambiente bem mais amplo do que o projeto propriamente dito e as atividades dirias relacionadas sua existncia, portanto, significa adicionar fatores favorveis ao sucesso do projeto. Neste contexto encontram-se os dados relevantes, em uma fase inicial, para a elaborao de um estudo de viabilidade que ter por funo principal dar suporte para as primeiras decises de projetos, podendo at mesmo determinar o cancelamento ou adiamento das atividades. O contexto de um projeto abrange principalmente as fases, o ciclo de vida do projeto e as partes envolvidas. O estudo deste contexto chega a compreender as influncias do projeto na organizao, as habilidades da Administrao Geral e at as influncias scio-econmicas e ambientais. Como de praxe, dividir problemas complexos para torn-los mais gerenciveis uma tcnica tambm adotada nos projetos. Este grau de complexidade de um projeto diretamente proporcional pelo grau de unicidade do mesmo, gerando uma incerteza sobre at mesmo o sucesso do projeto. Delimitam-se ento as fases do projeto, onde se tenta dividir e organizar da forma mais adequada em um ciclo (Ciclo de Vida), que tambm tem a finalidade definir o incio e o fim de um projeto.

17

Este ciclo de vida, segundo o PMBOK, definir quais atividades sero desempenhadas em cada fase, quando sero gerados seus subprodutos, como estes sero revisados, verificados e validados, quem estar envolvido nas fases e como controlar e aprovar cada fase. Cada fase do projeto bem definida e deve produzir subprodutos necessrios para a continuidade do ciclo. As fases e esses artefatos produzidos asseguram de certa forma, o produto final e objetivo do projeto. importante implantar uma metodologia de avaliao do desempenho de projeto, estudando a continuidade do projeto e a validao dos artefatos. Geralmente estas fases so denominadas de levantamento de necessidades, projeto ou especificao, construo, testes, implantao, manuteno e outros de acordo com as peculiaridades da rea de aplicao. Apesar da idia de sequeciamento das fases de um projeto, implcita principalmente pela preocupao com os subprodutos gerados em uma determinada fase e importantes para uma fase subseqente, pode-se tomar a deciso de assumir riscos, quando aceitveis e gerenciados, para prover a caracterstica de concorrncia neste processo do ciclo, o que usualmente denominado de fast tracking genrico de um projeto.
10

. A Figura 2 representa um ciclo de vida

Figura 2. Exemplo genrico de ciclo de vida de um projeto. (Fonte: Adaptao PMBOK, 3th, 2004).

10

fast-tracking, termo utilizado na literatura de Gerncia de Projetos, em referncia ao parelismo na realizao de qualquer atividade e desta forma obtendo a compresso do cronograma.

18

Na metodologia de gerncia de projetos este ciclo de vida habitualmente representado e organizado em descries contidas em formulrios, diagramas e checklists , cujos possuem descries como custo e recursos humanos, entre vrios fatores. Durante estudos deste ciclo de vida de um projeto que vem sendo realizados em um grande perodo de tempo, vm demonstrando algumas heursticas, como: no incio, a probabilidade de terminar um projeto com sucesso baixa, sendo o risco e incerteza altos, e est probabilidade de sucesso vai aumentando medida que o projeto evolui. Uma outra questo importante tambm levantada: as partes envolvidas possuem uma alta capacidade de influenciar o produto final e o custo no incio do projeto, reduzindo com o andamento do projeto, visto que o custo, o risco de mudanas e correes de erros aumentam. Uma outra questo muito importante saber diferenciar o ciclo de vida do projeto e o ciclo de vida do produto. A Figura 3 demonstra de uma maneira simples a real diferena entres estes conceitos.

Figura 3. Relacionamento entre o ciclo de vida do produto e do projeto. (Fonte: Adaptao PMBOK, 3th, 2004).

Embora a preocupao maior ao se estudar o ciclo de vida seja definir qual esforo a ser realizado em cada fase, outro ponto crtico definir quem estar envolvido em cada fase. As partes envolvidas alm de englobar os agentes diretamente ativos no projeto, tambm envolvem aqueles que podem ser afetados com os resultados. Conhecer as necessidades e expectativas dessas partes e saber gerenciar os requisitos podem contribuir para a garantia de sucesso, apesar da dificuldade de gerenciar possveis conflitos oriundos destes tipos de requisitos. Essas partes geralmente so denominadas de Gerente de Projeto, Cliente, Organizao Executadora, Membros de Equipe, Patrocinadores e outros.

19

Alm de se perceber inmeras influncias de um projeto em uma organizao, ao se analisar o contexto tambm se toma cuidados com questes relacionadas : a) Liderana, atuando no direcionamento de esforos, estabelecimentos de vises, estratgias para alcance dos objetivos, motivao e inspirao. b) Comunicao, atuando na troca de informaes, seja ela formal, oral, escrita, interna ou externa. c) Negociao, atuando sobre os objetivos, custo, cronogramas, termos, condies contratuais, designaes e recursos. Estudadas e compreendidas inmeras questes e fatores relevantes no contexto de um projeto e tendo a noo da influncia destes no ciclo de vida no projeto, vale relatar que objetivando principalmente a organizao, atualmente, se tornou necessrio tambm adoo de padres e regulamentos. Segundo a ISO11, um padro um documento aprovado por um organismo reconhecido que prov, pelo uso comum e repetitivo, regras, diretrizes ou caractersticas de produto, processos, ou servios cuja obedincia no obrigatria. Enquanto que um regulamento um documento que estabelece caractersticas de produtos, processos e servios, incluindo condies administrativas aplicveis, cuja obedincia obrigatria.

2.3

Processos

Aps esta viso inicial sobre Gerncia de Projetos, compreendendo o contexto que o envolve, torna-se necessrio dar foco no ciclo de vida e enxergar os processos encapsulados dentro desse ciclo. Como a Gerncia um esforo interativo em seu contexto, exigi-se a capacidade de balancear interesses em prol dos objetivos do projeto. Martins (2004, p.17) relata que a Figura 4 representa de uma forma intuitiva os parmetros que necessitam ser gerenciados e balanceados adequadamente.

11

ISO - International Organization for Standardization. Organizao internacional responsvel por gerir padres.

20

Riscos

Aquisies

Integrao Prazo Qualidade Custo

RH Escopo

Comunicao

Figura 4. Principais variveis de um projeto. (Fonte: Adaptao Martins, 2004).

O melhor entendimento desta natureza, enfatizando a importncia desta integrao, descrever a gerncia em termos de processos e suas interaes. Desta forma, projetos so compostos de processos, que segundo o PMBOK (2004, p.38), significa uma srie de aes que geram um resultado . Esses processos, de uma forma geral so classificados como: 1. Processos da gerncia de projetos, que se relacionam com a descrio, organizao e a concluso do trabalho. Aplicveis a maioria dos projetos. 2. Processos orientados ao produto, que se relacionam com a especificao e a criao do produto do projeto. Variam de acordo com a rea de aplicao. Os processos de gerncia de projetos podem ser organizados em grupos que se caracterizam principalmente pelos subprodutos gerados ou foco de ateno no projeto. Cada um desses grupos pode conter mais de um processo. A Figura 5 ilustra o relacionamento entre esses grupos em cada fase.

21

Processos de Iniciao

Processos de Planejamento

Processos de Controle

Processos de Execuo

Processos de Encerramento

Figura 5. Relacionamento simplificado entre grupo de processos.

Em linhas gerais, os processos abrangem: Processos de iniciao: autorizao do projeto ou fase com reunies e brainstorm
12

, alm de estudos de interesse.

Processos de planejamento: definio, refinamento dos objetivos e seleo da melhor alternativa de ao para alcanar os objetivos que o projeto estiver comprometido a atender. Nesta etapa, tenta-se definir os melhores valores para os parmetros apresentados, tendo em vista as caractersticas do projeto. Muita documentao elaborada. Processos de execuo: coordenar pessoas e outros recursos para realizar o plano. Estes processos efetivam as necessidades e expectativas do projeto em um produto ou artefatos importantes para, principalmente, a fase posterior e a validao do processo como um todo. Processos de controle: assegurar que os objetivos do projeto esto sendo atingidos atravs da monitorao regular do seu progresso para identificar variaes do plano, portanto aes corretivas podem ser tomadas quando necessrias. Observando os processos de execuo, medidas cautelares ou at mesmo necessrias so geralmente adotadas para o alcance de eficincia no projeto, portanto, este processo inicia-se em uma fase muito matura do projeto e apenas termina com o fim do mesmo.

12

brainstorm, tcnica para coleta de informaes como requisitos, anseios, desejos e novas idias. Reunio coletiva de criao.

22

Processos de encerramento: formalizar a aceitao do projeto ou fase. Analisam-se resultados e postergam-se as melhores decises ou prticas como padres ou regulamentos, servindo como uma base de conhecimento para futuros projetos. Estes processos, por serem interativos e possurem uma relao de dependncia muito grande (anexo I), esto constantemente produzindo atualizaes, o que mostra a sobreposio de atividades em diversas intensidades. A Figura 6 ilustra a situao.

Figura 6. Sobreposio de atividades. (Fonte: Adaptao PMBOK, 2002).

Em um projeto com muitas fases, o que normal, as interaes tambm atravessam as fases, assim o encerramento de uma fase fornece as entradas necessrias para os primeiros processos da prxima fase. A Figura 7 demonstra como esse ciclo de vida se processa.

23

Figura 7. Processamento do ciclo de vida. (Fonte: Adaptao PMBOK, 2004).

Vale notar que os processos de iniciao em cada fase tornam consistente o projeto e focam as necessidades de negcio que justificaram a criao, podendo-se at mesmo resultar no interrompimento do projeto. Dentro de cada grupo de processos existem os chamados processos essenciais e os processos facilitadores. Os primeiros dizem respeito queles que o projeto muito dependente, em uma grande maioria de projetos. J os facilitadores, referem-se queles que podem auxiliar nas atividades e no ciclo do projeto como um todo, sendo muitas vezes adotados de acordo com as peculiaridades do projeto.

2.4

reas

Como j foi mencionado, a Gerncia de Projetos descrita em processos que atuam e foram organizados em nove reas (anexo II). Sero discutidas resumidamente no intuito de compreender futuramente onde as mesmas so relevantes para o projeto de software.

24

2.4.1 Integrao

O objetivo dos processos da Gerncia da Integrao prover coordenao aos diversos componentes de um projeto, uma real necessidade visto que, na gerncia de projetos, os processos que a descrevem so de natureza intrnseca interativos. Os processos envolventes nesta rea so: Iniciao: Reconhecimento formal da situao do projeto, seja a sua fase inicial ou incio de uma prxima fase, visando a autorizao para a continuidade ou incio de uma fase. Este reconhecimento pode ser feito atravs de avaliaes de requisitos, estudos de viabilidade, de um plano preliminar ou at mesmo de uma documentao formal adotada. Desenvolvimento do Escopo Preliminar: Visa a anlise e definio de um escopo preliminar, caracterizando-se por ser uma narrativa de escopo em alto nvel. Desenvolvimento do Plano de Gerncia do Projeto: Documentao formal e reconhecida pelas principais partes envolvidas, onde so especificados definies, premissas, decises, metas e objetivos, agregando fatores relacionados a todas as reas pertinentes ao projeto e servir como guia para a execuo. Execuo do Plano do Projeto: Processo de realizao do trabalho definido pelo Plano de Gerncia do Projeto e pelo Escopo Preliminar. So necessrios a coordenao e o direcionamento das atividades tcnicas e organizacionais visto que alta sua influncia no produto do projeto. Monitorao e Controle do Trabalho: Visa monitorar continuamente o desempenho definido pelo Plano de Gerncia do Projeto, controlando processos de todo o ciclo do projeto (iniciao, planejamento, execuo e fechamento). Controle Integrado de Mudanas: Objetiva os estudos e cuidados com os fatores que podem ser responsveis por mudanas no projeto, reconhecendo seu acontecimento e gerenciando-as no momento mais oportuno. Visando as integridades e requisitos do plano de projeto, principalmente em se referindo s referncias para o guia de desempenho. Fechamento do Projeto: Processos que formalizam o trmino do projeto e suas atividades.

25

No difcil de notar a necessidade da integrao em projetos, principalmente quando relembramos o contexto que envolve o projeto. Uma tcnica muito aplicada para a integrao e para mensurar o desempenho do projeto a EMV13.

2.4.2 Escopo

Visando gerir tambm processos necessrios para o projeto que garantam que todas as atividades necessrias para o alcance do sucesso seja um fato, elaborou-se a Gerncia do Escopo, cujo foco de preocupao est em definir e controlar o que est ou no no projeto. Seus processos so: Planejamento do Escopo: Elaborao do Plano de Gerncia de Escopo e documentao sobre a situao do projeto em relao a suas atividades, visando dar subsdios suficientes para decises futuras no projeto, incluindo como as divises de tarefas e produtos sero criados e definidos. Detalhamento do Escopo: O maior objetivo definir e detalhar os principais produtos do projeto, visando assim clareza na atribuio de responsabilidade, base de conhecimento para medio e controle de desempenho e preciso nas estimativas de custo, tempo e recursos. Criao do WBS14: Processos que realizam a subdiviso dos maiores artefatos e tarefas em menores, para torn-los componentes mais gerenciveis. Verificao do Escopo: Visa aceitao formal do escopo, at ento compreendido e documentado no projeto, pelas partes envolvidas no projeto dentro de seu contexto, exigindo uma reviso dos produtos e artefatos produzidos tanto em sua aceitao quanto em seu grau de exatido (Controle de Qualidade). Controle do Escopo: Visa acompanhar as mudanas e os fatores que as geram, para garantir que as mesmas sejam estudadas, discutidas e de certa forma previsveis, para que, quando ocorridas, as mesmas possam ser gerenciveis. Este processo deve se

13 14

EMV Earned Value Management. Gerncia de Valor Agregado. WBS - Work Breakdown Structure. Especificao da estrutura de trabalho.

26

integrar aos demais processos de controle (controle de prazo, controle de custo, entre outros).

importante colocar em questo a diferena entre escopo de produto e escopo de projeto. O primeiro refere-se aos aspectos e funes que caracterizam um produto ou servio, j o segundo, estende-se a todo o trabalho que deve ser realizado para fornecer um produto ou servio de acordo com o escopo do produto. Os processos vistos atuam sobre a gerncia de escopo de projeto, pois os processos referentes a escopo de produto so muito especficos da rea de aplicao e usualmente so definidos como parte do ciclo de vida do projeto. Apesar da distinta concepo entre os escopos de projeto e produto, o gerenciamento deve ser integrado para garantir qualidade no projeto como um todo. O gerenciamento desta rea deve ser capaz der traduzir todos os requisitos do projeto, sejam eles implcitos ou explcitos, em apenas explcitos, contribuindo assim para processos de controle como o de qualidade.

2.4.3 Prazo

Inclui os processos necessrios para assegurar que o prazo do projeto ser cumprido, com todos os artefatos e produtos produzidos em satisfao ao planejamento do projeto. Segue abaixo seus processos: Definio das Atividades: Envolve a identificao e documentao das atividades especficas necessrias para a produo dos artefatos e subprodutos, visando o objetivo do projeto. Sequenciamento das Atividades: Com as atividades definidas, este processo visa direcionar o foco dos esforos, estabelecendo em uma documentao formal (ex: PDM15, ADM16, CDM17) uma ordem de execuo e dependncias das atividades. Obtm-se o desenvolvimento de um cronograma consistente com a realidade do projeto.

15 16

PDM Precedence Diagram Method. Mtodo do Diagrama de Precedncia. ANEXO IV. ADM Arrow Diagram Method. Mtodo do Diagrama de Flexa. 17 CDM Condicional Diagram Method. Mtodo do Diagrama de Condicional. ANEXO IV.

27

Estimativa de Recursos das Atividades: Mensurar quantativamente os recursos que sero utilizados no projeto. Esta estimativa tambm leva em considerao aspectos significativos como experincia do grupo envolvido e histrico de atividades em projetos semelhantes anteriormente desenvolvidos. Estimativa da Durao das Atividades: Mensurar quantativamente no espao temporal os perodos necessrios para a implementao de cada atividade. Devem-se levar em considerao o escopo e os artefatos gerados pelo processo anterior, encontrando em conjunto com outros fatores, como a necessidade de um cliente, as dificuldades no estabelecimento de uma estimativa da durao total do projeto. Desenvolvimento do Cronograma: Analisar (ex: CPM18, GERT19, PERT20) os resultados obtidos do sequenciamento e estimativa, conjuntamente com os fatores chaves de um projeto como escopo e recursos disponveis, visando o desenvolvimento do cronograma. Este por sua vez constar de datas-marco estabelecendo o incio e fim de atividades em realidade com planejamento do projeto. Este artefato (ex: Diagramas de Gantt, Diagrama de Marcos) deve ser produzido de uma forma interativa permitindo que entradas de outros processos e de uma base de conhecimento do pessoal encarregado para elaborao do mesmo possam se associar e influenciar na sua criao. Controle do Cronograma: Envolve o controle sobre os fatores que criam mudanas e a determinao das alteraes devidas no cronograma, alm de gerenciar as mudanas reais, levando-se em considerao parmetros de tempo e escopo.

Em projetos simples, que no envolvam cuidados com diversos parmetros, alguns desses processos podem ser tratados como um nico processo, devido inexistncia de complexidades que exigiriam todos os processos, artefatos e interfaces acima descritos.

18 19

CPM Critical Path Method. Mtodo do Caminho Crtico. ANEXO IV. GERT Graphical Evaluation and Review Technique. Tcnica de Avaliao e Reviso Grfica. 20 PERT Program Evaluation and Review Technique. Tcnica de Avaliao e Reviso Programada. ANEXO IV.

28

2.4.4 Custo

Nesta rea incluem-se os processos necessrios para garantir que os requisitos oramentrios aprovados sejam cumpridos. Abaixo, seus processos: Estimativa dos Custos: Visam o desenvolvimento de uma estimativa dos custos planejados pelos processos anteriores, envolvendo a elaborao de avaliaes quantitativas de vrias alternativas de custos e seus respectivos provveis resultados. Em muitos casos, essas estimativas so determinadas por analogias encontradas dentro de uma base de conhecimento e experincias em outros projetos, em conjunto com modelagens paramtricas (modelos matemticos) de acordo com as caractersticas do projeto. Elaborao do Oramento dos Custos: A preocupao est na alocao das estimativas de custos s atividades individuais com a finalidade de estabelecer um guia de custo para permitir mensurar o desempenho. Controle dos Custos: Processos que visam influenciar os fatores que criam as mudanas do guia de custos e determinar as alteraes que devero ser feitas, gerenciando parmetros de tempo e escopo. Esses processos melhoram o desempenho do custo, compreendendo as causas pelas variaes do plano, registra em uma documentao as mudanas oramentrias ocorridas at mesmo para ttulo de informao para todas as partes envolvidas e, principalmente, gerenciar os custos esperados dentro dos limites aceitveis do projeto.

de praxe que as estimativas de custo sejam feitas depois de uma aprovao do oramento, entretanto o correto e aconselhvel que estas estimativas sejam elaboradas antes de se submeter o oramento do projeto para a aprovao.

2.4.5 Qualidade

uma rea muito visada em qualquer projeto e que envolve o comprometimento de muitos elementos do contexto, incluindo at mesmo as polticas gerenciais adotadas. Inclui os

29

processos necessrios que visaro garantia da realizao e satisfao de todos os requisitos do projeto. Uma viso simplificada desta rea pode ser compreendida atravs de seus processos: Planejamento da Qualidade: Processos que tero como foco coletar, analisar e identificar padres de qualidade relevantes, estipulando a maneira pela quais esses padres sero implantados. um dos processos colaborativos mais importantes para o planejamento do projeto, alm de possuir muita influncia sobre fatores como custo, prazo, escopo e at mesmo risco. (PMBOK). Garantia do Desempenho em Qualidade: Implementao das atividades planejadas e sistematizadas, compreendendo tambm a avaliao rotineira do desempenho, tanto das atividades gerais do projeto como das atividades focadas na qualidade, como forma de assegurar a satisfao dos padres adotados em todo o escopo planejado pela gerncia, portanto, deve ser executado ao longo de todo o projeto. Controle do Desempenho da Qualidade: Processos que estaro monitorando e gerindo os artefatos ou produtos produzidos de forma a obter conhecimento sobre a satisfao dos requisitos do projeto e, caso necessrio, identificar os fatores geradores de quebra de padres e gerenci-los de uma forma adequada para elimin-los do projeto no momento mais oportuno. Como tambm um processo que acompanhar todo o projeto, os resultados dos produtos so somados com os resultados do gerenciamento tais como custo e prazo. A qualidade planejada, no inspecionada

Antes da elaborao de normas e procedimentos de qualidade, todos os processos que visavam qualidade no projeto eram compreendidos de uma forma simplificada no processo de Garantia de Qualidade, apenas. Durante estes processos de fundamental importncia utilizar-se de alm das tcnicas de planejamento de projeto, usufruir de outras que se aplicam de acordo com a rea de aplicao empreendida, ou seja, alm de se ter a implementao do gerenciamento da qualidade do projeto, importante gerenciar a qualidade do produto do projeto. Iniciativas como Gesto da Qualidade Total podem melhorar ambos. O controle deve estar provido de uma equipe capacitada para conhecer prticas (Inspeo, Cartas de Controle, Diagrama de Pareto, Amostragem Estatstica, Fluxogramao, Anlise de Tendncias, etc.) que se utilize de estatstica e probabilidade para a elaborao de dados relevantes para a tomada de decises da gesto do projeto.

30

2.4.6 Recursos Humanos

Processos responsveis por programar o uso efetivo e eficaz dos recursos humanos envolvidos no contexto do projeto. Abaixo, seus processos: Planejamento dos Recursos Humanos: Anlise do contexto na iniciativa de identificar os papis e seus relacionamentos dentro do projeto, sejam eles individuais ou pertinente a um determinado grupo. Apesar de estar fortemente relacionado com a fase inicial do projeto, este planejamento deve ser periodicamente revisado para assegurar continuidade e eficincia do projeto. Montagem da Equipe: Alocao e designao dos recursos humanos do projeto, de forma a garantir que os requisitos sero atendidos. Desenvolvimento da Equipe: Processos que visam o desenvolvimento de competncias individuais e de grupo para elevar o desempenho do projeto, seja elevando o desempenho individual, seja elevando o nvel de desempenho das equipes. Gerncia da Equipe: Processos responsveis por resolver problemas gerados por conflitos interpessoais ou quaisquer outros problemas relacionados aos recursos humanos que possam influenciar no adequado andamento do projeto.

Processos que perduram por todo o projeto so altamente influenciados por questes relacionadas a recursos humanos como Liderana e Motivao, complementadas com fatores relacionados sade e segurana.

2.4.7 Comunicaes

Trata-se da rea competente por gerenciar as informaes do projeto. Seus processos visam a garantia de que os dados relevantes coletados sero condicionados a servir todos os processos envolvidos na gerncia de projetos. Prove a necessria relao entre as partes envolvidas com seus conhecimentos e idias, tambm necessrios para a gesto de

31

conhecimento, que contribuiro para a gerncia desta rea. Basicamente, seus processos so divididos em: Planejamento das Comunicaes: Produo de uma documentao formal provindo da preocupao de se assegurar que todas as partes envolvidas no projeto estaro apoiadas em requisitos de informao e comunicao relevantes para a realizao das devidas atividades, obtendo ambas quando e como necessitarem. Distribuio das Informaes: Processos que determinaram disponibilidade regular da comunicao e das informaes geridas pelo planejamento, contribuindo tambm para geri-las em momentos inesperados. Relato de Desempenho: Visa coleta e universalizao das informaes de desempenho que, quando analisados, permitiram aes corretivas ou evolutivas em tempo hbil. Com a vasta produo de relatrios (de Situao, de Progresso, de Previses, Valor Agregado, etc.) informaes sobre custo, escopo, prazo, qualidade, riscos, aquisies e outras so importantes para todos os outros processos contribuindo para somar artefatos que ajudar no guia de desempenho. Controle de Expectativas dos Stakeholders
21

: Processos que formalizam a concluso

do projeto ou de uma fase divulgando as informaes e seus resultados. Coloca-se em pauta a garantia de atendimento dos requisitos do projeto ou da fase em relao ao esperado pelos Stakeholders , a anlise do sucesso, efetividade e tambm artefatos que serviro para somar os dados de uma base de conhecimento da empresa para futuras fases ou projetos.

A identificao e adequada distribuio das informaes e comunicao entre as partes envolvidas, alm de determinar os meios adequados para o atendimento das necessidades decorrentes das atividades do projeto, so pontos de fundamental importncia para o seu desempenho, sendo um dos pontos crticos do projeto que levaram a concepo da Gesto de Conhecimento22.

21 22

stakeholders, referente a pessoa que possui aes e/ou interesses dentro de uma empresa. Gesto de Conhecimento, mapear e identificar o conhecimento para possibilitar seu compartilhamento dentro da empresa.

32

2.4.8 Riscos

Riscos so eventos ou condies incertas que possuem efeitos e, dependendo do projeto, causas inapropriadas para o seu contexto. Processos sistemticos para assegurar que os riscos de um projeto sero identificados, analisados e resolvidos, provendo a melhor capacidade do projeto de baixar a probabilidade de eventos adversos aos objetivos do projeto. Estes processos so: Planejamento da Gerncia de Riscos: Processos que decidiro a abordagem e planejamento da gerncia de riscos, analisando seus tipos, nveis e visibilidades. Identificao dos Riscos: Processos interativos que visam determinao dos riscos estudados e caracteriza-los de uma forma a garantir que todo o contexto estar provido de segurana. Anlise Qualitativa de Riscos: Processos que visam ponderao qualitativa dos riscos e condies para priorizar de acordo com efeitos e causas. Formaliza-se a importncia de se tratar dos riscos e a maneira como respond-los. Anlise Quantitativa de Riscos: Processos que visam mensurao da probabilidade dos riscos e suas respectivas conseqncias nos objetivos do projeto. As tcnicas empregadas (Simulao de Monte Carlo, DT23, CRS24, etc.) oferecem a determinao dessas probabilidades, a quantificao da exposio aos riscos, dimensionamento de fatores para a contingncia, priorizao por parcela de efeito adverso e formalizao de parmetros reais para todos os outros processos. Planejamento de Contingncia: Elaborao de procedimentos e tcnicas preventivas e/ou evolutivas no sentido tanto de reduzir ameaas quanto de aumentar a capacidade de reao a possveis e indesejveis ocorridos. Controle e Monitorao de Riscos: Processos que visam monitorar (ex: Registro de Mtricas) o contexto em busca de resduos e/ou indcios de ameaas, identificao de novos riscos, execuo do plano elaborado por processos anteriores e, por fim, avaliar o desempenho dessas tarefas.

As premissas do projeto no podem desaparecer ou tornar-se invlidas por possveis aes remediadoras, interferir nos objetivos no projeto no de relevncia para os processos
23 24

DT- Decision Tree. rvore de Desio. ANEXO IV. CRS Cost Risk Simulation. Simulao de Custo de Risco. ANEXO IV.

33

de gerncia de riscos e sim de agregar conhecimentos e atividades para evitar que qualquer componente de todo o ciclo do projeto seja ameaado e de servir como suporte para decises estratgicas. Isto tambm ganha sustentao quando muitas vezes riscos so assumidos na tentativa de melhorar o desempenho no processo como um todo ou do produto final, seja ele de uma fase ou do projeto.

2.4.9 Aquisies

Compreende os processos comprometidos em gerir a obteno de bens e servios externos organizao executadora. Abaixo, seus processos: Planejamento das Aquisies: Processos com foco na determinao de qual o produto a ser contratado, como, quanto e quando. Planejamento dos Contratos: Envolve a elaborao da documentao com os requisitos e requerimentos do produto desejado e a identificao dos fornecedores potenciais para a possvel licitao. Obteno das Propostas: Com a devoluo das propostas, este processo iniciado para que as mesmas possam ser analisadas para ter conhecimento dos fornecedores em potencial. Seleo de Fornecedores: Ponderao de fatores, incluindo valores, para efetuar a seleo de um ou mais fornecedores, classificando-as de forma a garantir o processo legvel para as pessoas envolvidas nestes processos. Administrao dos Contratos: Processos que cuidaro do relacionamento entre o projeto e os fornecedores envolvidos, tomando como ponto importante a interface das necessidades de ambas as partes e levando em considerao todas as medidas legais. Encerramento do Contrato: Liquidao de possveis pendncias e concluso do contrato, com possveis revises para aceitao e verificao do produto adquirido.

Os parmetros deste gerenciamento esto associados a parmetros de outras reas como escopo, custo, risco e at qualidade. Lidar com recursos, sejam eles humanos ou materiais, principalmente quando so de origem externa, sempre uma tarefa que exige

34

ateno, pois os problemas gerados por possveis falhas nesta rea podem acarretar ameaas para o desempenho do projeto.

35

PROCESSO DE SOFTWARE

3.1

Fundamentos

Primeiramente, interessante falar sobre um produto intangvel que, ora em um pequeno empreendimento ora em uma multinacional, tem o objetivo principal de coordenar atividades e sistematizar dados, provendo apoio ao empreendimento para o mesmo alcanar seus objetivos e metas: O Software. Seja embutido em um pequeno aparelho celular para ser usado como fonte de entretenimento, seja em uma grande rede bancria para ser usado no gerenciamento de transaes ou at mesmo em uma mquina robotizada para auxiliar em procedimentos mdicos, o Software agregou valores, devido os desafios em que o mesmo foi submetido. Acreditar no potencial de mquinas, que por algum tempo apenas realizavam clculos matemticos, era desafiar o prprio homem. Com o avano da tecnologia e com o impulso proporcionado por vrias reas da Computao, o Software passou a ter papel fundamental dentro de muitas reas de aplicao do conhecimento, atuando em seus processos e, geralmente, contribuindo para um slido e eficaz uso de informaes relevantes para as mesmas. Mediante o cenrio competitivo do mundo dos negcios nos ltimos anos e colocando em pauta a rea tecnolgica, questes como automatizar e integrar processos, compartilhar dados e utilizar informaes em tempo-real, passaram a exigir da engenharia de software conceitos e metodologias melhores e eficazes. J em meados dos anos 70, previa-se a Crise do Software
25

, que colocou em

polmica a utilizao e produo de software. Alguns dos motivos estavam relacionados impreciso nas estimativas de custos e durao, s deficincias na identificao dos requisitos, falta de produtividade das equipes, falta de qualidade e confiabilidade do software e por fim a grande dificuldade de manuteno. Surge ento o conceito Processo de Software: um conjunto de atividades bem definidas, apoiadas por metodologias e ferramentas, que so contextualizadas dentro de um

25

Crise do Software. NAUR, P. Randell B. Software Engineering. Rept. NATO Sci. Comm., 1969.

36

empreendimento produzindo artefatos que auxiliam no projeto eficaz de software com qualidade, respeitando prazos e custos. Um mtodo formal, flexvel, previsvel e replicvel surgiu dentro de uma grande empresa de tecnologia, a Rational, e foi denominado de RUP, ganhando destaque entre vrios outros processos que colaboravam para a cadeia produtiva de software. Este processo apesar de fornecer uma viso ampla e compartilhada do ciclo de vida de um projeto de desenvolvimento de software, tambm permite customizaes (instncias) para se adequar a necessidades especficas. O RUP visa um desenvolvimento interativo e incremental de forma a proporcionar um melhor gerenciamento de todo o ciclo de vida de qualquer projeto de software em qualquer tipo de organizao, utilizando-se do paradigma de Orientao Objetos, e consequentemente, da UML. A UML uma linguagem notacional de grande aceitao no mercado para a especificao de software orientado a objetos, elaborada sobre um conjunto de notaes e padronizada por um rgo competente de reconhecimento mundial para a Engenharia de Software, a OMG26 ( Object Management Group ). Todo este processo baseado em 3 (trs) elementos chaves: ator, atividade e artefato. Durante o fluxo do trabalho no ciclo de vida do software, que define a seqncia das tarefas a serem realizadas dentro de nove disciplinas, basicamente o ator realiza e produz, respectivamente, um conjunto especfico de atividades e artefatos. A arquitetura deste processo de desenvolvimento de software constituda de 2 (duas) dimenses: Horizontal: representa o tempo e mostra os aspectos do ciclo de vida dos processos, expressando as questes dinmicas. Vertical: representa o fluxo, que agrupa as atividades, expressando as questes estticas. A Figura 8 descreve essa arquitetura com seus processos e fases.

26

OMG

Object Management Group. www.omg.org.

37

Figura 8. Dimenses do RUP. (Fonte: Adaptao Kroll & Kruchten, 2003).

Como se pode ver, este processo divide o ciclo em 4 (quatro) fases, so elas: 1. Incio ou Concepo: Definio de parmetros importantes para o transcorrer das atividades subseqentes, como por exemplo, o escopo. Espeficicao da viso do produto. Aprovao dos stakeholders em relao aos parmetros definidos.

Descriminao dos Casos de Uso crticos que serviro de guia para as prximas decises de projeto. Anlise do projeto arquitetural necessria para a satisfao do software. Anlise inicial de Riscos. 2. Elaborao: Planejamento e formalizao de requisitos de uma forma mais abrangente (Viso global). Definio da arquitetura. Eliminao dos riscos mais relevantes ao projeto. 3. Construo: Efetiva implementao e validao do produto definido e planejado, incrementalmente. Desenvolvimento de componentes guiado pelo projeto arquitetural. Minimizar custos e prazo. Desenvolvimento de verses. Formatao do manual do usurio. 4. Transio: Implantao do produto em ambiente de produo. Avaliao do produto pelos usurios finais. Converses e Migraes. Treinamento. Avaliao e concluso do projeto.

38

A caracterstica de desenvolvimento, onde h um projeto e a construo em sucessivas interaes incrementais, permite teste e validaes de artefatos produzidos assim como preveno de riscos. As interaes do RUP suportam 9 (nove) disciplinas, sendo 6 (seis) delas provendo apoio aos processos de Engenharia e 3 (trs), processos de Suporte. Essas disciplinas so: 1. Modelagem de Negcio: Visa produo formal de documentos que retratam o contexto do negcio onde est inserido o sistema a ser desenvolvido e que sero posteriormente refinados com o decorrer das interaes. 2. Requisitos: Visa constante validao das funcionalidades que o sistema dever desempenhar, produzindo tradues para equipe de desenvolvimento e informaes para a gerncia do projeto. 3. Anlise e Projeto: Visa produo de especificaes formais do sistema a ser implementado, definindo a arquitetura e outros fatores como desempenho e escalabilidade. O detalhamento maior no Projeto, onde fatores como tecnologia, SGBD, GUI e outros, so submetidos a uma avaliao de acordo com as especificaes. 4. Implementao: Visa definio da organizao do cdigo fonte, implementao dos componentes, execuo de teste de unidade e interao dos elementos. 5. Teste: Visa verificao da qualidade do produto, com teste de unidade, de integrao, do sistema e de aceite. 6. Implantao: Visa disponibilidade do software para o usurio em ambiente de produo, treinamento e possvel migrao de dados. 7. Gerncia de Projeto: Visa monitorao e controle das atividades e artefatos produzidos, alm de fatores relevantes para a empresa como prazo e qualidade, entre outros. 8. Gerncia de Configurao e Mudanas: Visa administrao das mudanas e da evoluo dos artefatos produzidos. Um processo bem definido que gerencia desde o controle das solicitaes at a anlise de impacto e aprovao da mudana. 9. Ambiente: Visa definio dos processos (ex: rotinas de Backup ) e ferramentas para a empresa que se utilizar do sistema, incluindo a seleo, aquisio, instalao, configurao de toda a infra-estrutura necessria. Dentre essas disciplinas, o foco de atividades e artefatos produzidos de acordo com o momento do projeto.

39

Um ponto essencial para a motivao deste processo de software ressaltado quando dizemos que o mesmo pode ser aplicado a qualquer organizao. Isto significa dizer ele provido das caractersticas necessrias para ser um framework , ou seja, capaz de se adaptar ou ser at mesmo ser estendido para atender as necessidades, caractersticas, restries, domnio e cultura de uma organizao. Isto tambm significa que ele consegue ser flexvel mesmo sendo formal, permitindo que no sejam produzidos artefatos desnecessrios ou com baixo valor agregado e que regras ou procedimentos especficos da organizao tambm complementem o processo.

3.2

Melhores prticas

Como o RUP surgiu em meio de grandes evolues na rea de Engenharia de Software, acabou por absorver as melhores prticas de desenvolvimento de software para vir a se tornar to sofisticado e este conjunto o ncleo do framework RUP. A seguir, um breve comentrio sobre cada delas, importante para garantir as caractersticas e importncia do RUP.

3.2.1

Interatividade

A seqncia de atividades no linear e obrigatria como em outros processos (ex: Waterfall

27

), sendo assim, o que vai determinar a seqncia real das atividades vai ser um

conjunto de caractersticas, necessidades e objetivos do projeto. Com isso, as mudanas de requisitos, que so freqentes em projetos de software, so mais bem gerenciadas e a integrao ou implementao deixa de ser uma questo de preocupao apenas em uma fase final e passa a ser considerada progressivamente durante as interaes do processo.
27

Waterfall, referente ao mtodo cascata de desenvolvimento de software, onde h um sequenciamento de atividades mais simples.

40

Os riscos, que geralmente so descobertos e endereados durante a integrao ou implementao, passam a ser considerados mais prematuramente no projeto e de forma menos onerosa, assim, tem-se a capacidade de testar adequadamente todos os componentes desenvolvidos e exercitando ferramentas e habilidades. A interatividade facilita a produo de verses do software, muitas vezes importantes para assegurar a verificao e validao dos requisitos e de acordo com o planejamento das atividades e seus respectivos produtos, aumenta o potencial de reusabilidade de componentes. As interaes fazem com que os recursos e artefatos sejam utilizados e produzidos em momentos adequados. Assim, todas as habilidades se iniciam rapidamente (Analistas, Projetistas, Desenvolvedores, Testadores, etc.) evitando a m utilizao principalmente de recursos alocados para o projeto. No RUP a prtica da interatividade bem definida e controlada e os objetivos so mensurados a cada interao, garantindo o refinamento e melhora do processo de desenvolvimento, seja em termos de artefatos (documentaes, componentes, etc.) e fatores (cronograma, escopo, etc.), seja em termos mudanas na prpria organizao ou no processo.

3.2.2

Gerncia de Requisitos

Trata-se da tcnica sistemtica para coletar, organizar, comunicar e controlar os requisitos e as suas constantes mudanas, visando, principalmente, gerir a complexidade do projeto de desenvolvimento de software. As correes mais onerosas para um projeto de desenvolvimento de software so as que esto diretamente relacionadas aos requisitos e um dos benefcios da prtica em questo a reduo dos custos e atrasos. O fator fundamental para se medir a qualidade do software se o mesmo faz aquilo o que foi projetado para fazer, portanto, a gerncia de requisitos uma prtica essencial para qualquer projeto. Com o RUP pode-se estimar mais facilmente estas medidas de qualidade e, com isso, melhorar a qualidade e satisfao do cliente.

41

A ferramenta mais importante para apoiar esta prtica no RUP a utilizao de Casos de Uso ( Use Case
28

), que define o comportamento realizado pelo sistema (funcionalidades

externamente observveis e os papis que interagem com as mesmas) e fornece uma ligao entre os requisitos e outros artefatos produzidos como arquitetura do sistema e plano de testes. Por isso, o RUP considerado um processo dirigido a Caso de Uso, ou seja, os Casos de Uso definidos servem como guia para todas as fases do processo de desenvolvimento.

3.2.3

Arquitetura baseada em componentes

Segundo Bass, Clements & Kazman (1998), define-se arquitetura de software como ... as estruturas do sistema que abrange os componentes de software, as propriedades externamente visveis desses componentes e as relaes entre eles , sendo atravs da arquitetura do software que anlises de efetividade e risco do projeto so realizadas em diversas alternativas estudadas para a construo do sistema a ser informatizado como um topo. Devido importncia deste conceito em um projeto de software, as primeiras interaes tm como foco a produo e validao da arquitetura do software, servindo como base para decises de projeto e para a construo das primeiras verses. O RUP prove uma maneira metdica e sistemtica para projetar, desenvolver e validar a arquitetura. Um componente de software pode ser definido como um pedao no trivial de software que realize ou satisfaa uma abstrao do projeto, tenha seus limites claros e podem ser integrados facilmente em uma arquitetura bem definida, por exemplo, um mdulo, um pacote ou um subsistema que executa uma funcionalidade especfica. No projeto de componentes existem atividades especficas que visam identificao de restries arquiteturais e outros elementos significantes. Nas primeiras interaes tm-se os cuidados necessrios para a elaborao do projeto arquitetural e a definio dos maiores riscos tcnicos. Em uma arquitetura baseada em componentes, os mesmos podem ser definidos, projetados, implementados e testados individualmente, e gradativamente sendo integrados no

28

Use Case. Casos de Uso. Usado para Anlise de Requisitos.

42

software. Isto tambm permite que eles sejam reusveis e comercializados (ActiveX, CORBA, JavaBeans, EJB, etc). No RUP, as interaes permitem que desenvolvedores identifiquem progressivamente os componentes e decidam qual deles desenvolver, quais reutilizar ou at mesmo quais deles comprar. O foco na arquitetura excelente para articular e organizar a estrutura do software, definindo padres pelos quais os componentes interagem entre si, alm de favorecer testes individualizados e incluir gradativamente conjuntos maiores de componentes.

3.2.4 Modelagem Visual

A modelagem foi inclusa nos processos de desenvolvimento de software para simplificar a realidade e com isso ajudar a entender os problemas e projetar as solues. A prtica de modelagem constantemente empregada nos processos do RUP e os artefatos produzidos so obtidos atravs do desenvolvimento e manuteno de modelos padronizados e muito bem documentados. A notao que apoia o RUP em suas fases e interaes a UML, contribuindo para a padronizao e fornecendo meios suficientes para extenses, em prol de se adequar a novos conceitos e tecnologias, caso necessrio.

3.2.5

Controle de Qualidade

Inclusa nas melhores prticas dos processos de software, est a continua verificao da qualidade. Como se sabe, a qualidade no algo que uma pessoa pode adicionar em um produto e sim algo planejado e controlado no projeto, sendo de responsabilidade de todos os membros do projeto. O conceito de qualidade est relacionado a duas reas dentro de um projeto de desenvolvimento de software: a) Qualidade de Produto: est diretamente relacionada ao produto produzido pelo processo e os elementos que o compe.

43

b) Qualidade de Processo: est diretamente relacionada ao processo, incluindo o seu grau de aceitao e implementao incluindo outros critrios e medidas de qualidade. No RUP, tanto a qualidade de produto quanto a de processo so apoiadas pela qualidade dos artefatos produzidos.

3.2.6

Controle de Mudanas

Por assumir uma caracterstica interativa, natural que muitas modificaes nos produtos do trabalho aconteam. Portanto, garantir que todos os produtos e todos os envolvidos no processo estejam sincronizados com os requisitos e necessidades estudados, fundamental. Esta prtica visa controlar as mudanas necessrias que por ventura ocorreram em meio a flexibilidade provinda da interatividade. O RUP favorece uma sistemtica para gerenciar essas mudanas de requisitos, de projeto e de implementao, e tambm, a monitorao de atividades importantes e erros, associando-os com artefatos especficos e verses do produto. Dentro do RUP, esse controle est aglutinado principalmente com o controle de configurao.

44

GERNCIA DE PROJETO DE SOFTWARE: PMBOK e RUP

4.1

Consideraes Iniciais

Por vrias peculiaridades do produto software e pelo fato de o seu desenvolvimento exigir o comprometimento com inmeros fatores, gerenciar um projeto de desenvolvimento de software em meio s necessidades atuais uma atividade difcil e exigente. A questo principal para essa abordagem diferenciada est justamente no software. Inicialmente este produto apenas concebido e formalizado em meio de anlises de processos especficos de uma determinada rea de aplicao e contexto da empresa. O que est sendo planejado dificilmente ser, de forma precisa, o produto final. E isto no se adequa a maioria de metodologia e tcnicas tradicionais para gerenciar o ciclo de vida de produtos, onde geralmente aplica-se a decomposio do produto e utiliza-se um processo seqencial, uma herana da indstria. Isso decorrente das constantes e necessrias mudanas dos requisitos, sejam elas por uma simples idia do usurio, seja por uma necessidade tecnolgica do mercado ou at mesmo pela evoluo dos processos dentro da empresa. A responsabilidade de gerir essas mudanas em um projeto de software somadas, em muitas vezes, com o valor que esse software representa nas decises e estratgias dentro de uma empresa, fundamentaram o aprimoramento dos processos gerenciais. Como j foi visto, existem os processos de gerncia de projetos e os processos orientados ao produto. Segundo Thayer & Dorfman (2002), h um consenso na literatura de que a gerncia ou a ausncia de gerncia um dos aspectos mais crticos dos projetos de

software . Como proposta para remediar e prover um suporte para a gerncia de projetos de desenvolvimento de software, foi apresentado o PMI, formalizando seus processos no PMBOK, e o RUP com o apoio da UML e aglomerao de excelentes prticas conhecidas no mercado. Com essa concepo e abordagem provinda de um projeto de desenvolvimento de software, prope-se utilizar o PMI para os processos de gerncia de projetos e o RUP para os processos orientados ao produto. Vale ressaltar que, apesar de que dentro das reas atuantes do processo de software RUP existir a Gerncia do Projeto, sua limitao diretamente proporcional importncia

45

deste projeto dentro da empresa e a interao com os processos gerenciais da mesma. Estas limitaes so ntidas principalmente na gesto de pessoas, oramento e contratos, e no apenas nestes pontos especficos, mas em todas as fases e interaes do RUP, o PMI pode contribuir para a gerncia do projeto como um todo. Essas limitaes tiveram origem com a prpria evoluo da Gerncia de Projetos. A maioria das tradicionais regras e responsabilidades ficou defasada e inadequada em face as novas demandas, principalmente em se tratando da indstria de Tecnologia de Informao, onde mudanas e inovaes acontecem com velocidade superior s demais.

4.2

Relacionando o PMBOK e o RUP

Aps a viso geral dos principais conceitos envolvidos nos processos de gerncia de projetos e processos de desenvolvimento de software, interessante mostrar a real possibilidade da execuo da combinao das duas metodologias em benefcio de qualidade e eficincia em um projeto de desenvolvimento de software. Hoje em dia existem inmeros processos particulares dentro das empresas, que foram definidos e suportados mediante a base de conhecimento presente e as condies administrativas. Entretanto, grandes entidades que visam o aprimoramento de processos em diversas reas, vm contribuindo com a concepo de padres mais eficientes. E foi neste sentido que duas empresas, a IBM e a PMI, desenvolveram duas metodologias apuradas e j aceitas no mercado pelos seus resultados. Se beneficiar de todo o conhecimento destas pode ser gratificante e refletir em melhores resultados. A escolha de prticas e metodologias depende diretamente da natureza do projeto e todo o seu contexto. Mediante inmeros processos desenvolvidos para um projeto de software, alguns se destacam por atender muito bem tipos especficos de projetos, entretanto, importante compreender processos que tem o diferencial de ser padronizado, abrangentes e genricos e de ser aceito no mercado. Percebe-se que tanto o PMBOK quanto o RUP descrevem guias baseados nas melhores prticas e so independentes de ferramentas, podendo ser aplicados em projetos de diversos tamanhos e necessidades. O primeiro rene conhecimentos genricos para o ciclo de vida de projetos, j o segundo prescreve prticas genricas de desenvolvimento do ciclo de

46

vida de software. O PMBOK projetado para ser aplicado em todos os processos de negcio existentes, enquanto o RUP projetado para ser implementado nos processos relacionados ao desenvolvimento de software. O PMBOK preocupa-se com a Gerncia de Projetos, cobrindo todos os aspectos relevantes na gerncia de um projeto, sendo descritivo e possuindo fases dependentes do domnio da aplicao. O RUP especfico para projetos de software, alm da gerncia de projetos, atua em outras disciplinas, limitada a sua preocupao com os aspectos da gerncia, sendo prescritivo e possuindo fases e interaes especficas para o desenvolvimento de software. Empresas, ao investirem muito dinheiro em um projeto de software, esperam e so exigentes quanto aos resultados e qualidade do produto. Principalmente porque este projeto, geralmente, tem o intuito de suportar decises estratgicas e essenciais dentro de um contexto competitivo. Justamente por isso, hoje, tem-se a necessidade emergente de melhorar a interao entre todas as partes envolvidas e gerenciar as informaes relevantes em toda a empresa e como proposta temos a combinao do PMBOK com o RUP. Portanto, o mapeamento entre estas duas metodologias para diminuir o gap existente entre os interesses e conceitos, importante e pode ser fundamental para o sucesso nos projetos de desenvolvimento de software. Em detalhe, a ligao do PMBOK concretizada pela rea de Gerncia de Projeto do RUP. Para a realizao desta ligao so necessrias algumas consideraes: a) b) c) Definio da configurao do RUP, comumente chamada de instncia; Garantia do pleno conhecimento dos elementos do PMBOK e do RUP; Mapeamento das regras, processos (referentes a gerncia de projeto), subprodutos,

atividades e artefatos do PMBOK e RUP; Reportaremos neste trabalho, apenas algumas heursticas e uma proposta para um mapeamento simplificado, considerando esta questo a relevante na ocasio.

4.3

Mapeamento entre reas e Atividades.

Embora existam diversas propostas para uma conciliao entre as interfaces dos processos do PMBOK e do RUP, o importante que eles sirvam apenas como um guia extra

47

de conhecimento para que este mapeamento seja elaborado de acordo com todo o ambiente e a realidade da empresa, mostrando neste ponto certo grau de subjetividade em relao ao paradigma de gerncia j desenvolvido pela mesma. A pessoa ou grupo de pessoas que so responsveis pela sua concretizao deve ter plenas competncias e afinidades com as reas, as atividades e artefatos de ambas as metodologias. A elaborao deste mapeamento prove um excelente exerccio no somente para implementar conhecimentos importantes, mas tambm para dar maturidade e aprofundamento a todos os processos envolvidos dentro do negcio em questo. Geralmente, este mapeamento realizado atravs das atividades e produtos desenvolvidos dentro de cada metodologia, devido suas naturezas estarem estruturadas dinamicamente em processos. Uma atividade do RUP analisada e atribuda para uma atividade ou processo do PMBOK, ou vice-versa. Na realidade, o fator principal fazer com que as duas se complementem e sejam suficientes uma a outra, somando suas qualidades e benefcios e oferecendo o melhor para a empresa. A Figura 9 tenta mostrar a ligao entre o PMBOK e o RUP atravs da disciplina Gerncia de Projetos do RUP.

Figura 9. Ligao entre o PMBOK e o RUP atravs da Gerncia de Projetos-RUP.

48

Segundo Charbonneau (2004, p.11), um detalhe notacional importante de mencionar que no RUP o agrupamento estrutural de atividade ( Strucural Activity Grouping ) provido atravs de Disciplinas (Modelagem do Negcio, Requisitos, Anlise e Projeto, Gerncia de Projetos, etc.) e no PMBOK, atravs de reas de Conhecimento (Custo, Prazo, Comunicao, Integrao, etc.). O agrupamento temporal de atividade ( Temporal Activity Grouping ), no RUP provido atravs de fluxo de trabalho ( Workflow ) j no PMBOK, atravs de grupo de processos ( Process Group ). Para iniciar o mapeamento do RUP com o PMBOK, devemos compreender como interao entre as disciplinas e as reas, respectivamente. Nos trabalhos de Charbonneau (2004, p.12), permite-se ter uma viso macro de como se inicia o processo de utilizao das duas metodologias conjuntamente alm de proporcionar um planejamento de atividades e artefatos. A Tabela 1 abaixo demonstra esse mapeamento inicial, de uma forma bem simples.

PMBOK -rea Integrao

RUP

Disciplinas

Gerncia de Projetos Requisitos Implantao Gerncia de Configurao e Mudanas

Escopo

Gerncia de Projetos Requisitos Gerncia de Configurao e Mudanas

Tempo Custo Qualidade

Gerncia de Projetos Gerncia de Projetos Gerncia de Projetos Gerncia de Configurao e Mudanas

Recursos Humanos Comunicao Risco Aquisio 9 (nove) reas

Gerncia de Projetos Gerncia de Projetos Gerncia de Projetos Requisitos 4 (quatro) disciplinas

Tabela 1. Mapeamento inicial.

49

Analisando este mapa, j percebemos uma sobrecarga de responsabilidades do projeto na disciplina Gerncia de Projetos do RUP. Isto acontece principalmente porque, como j foi discutido, o RUP tem o foco no produto Software e assim sendo, seus processos so orientados a este produto. Esta sobrecarga muitas vezes gera limitaes e/ou necessidades, que tambm j foram discutidas. Outro ponto interessante justamente a ausncia de algumas disciplinas do RUP neste mapa inicial. A justificativa mais simples para este relato, o fato de que as outras disciplinas so de carter do domnio de aplicao (Projetos de Software). Apesar desta ausncia, no significa que no exista alguma interao entre as mesmas e as reas do PMBOK, em momentos oportunos dentro do desenvolvimento de software, essas disciplinas ausentes neste mapa podem contribuir indiretamente atravs da Gerncia de Projetos (RUP). A seguir, este mapeamento ser detalhado atravs dos processos das reas do PMBOK com as atividades do RUP, segundo modelo proposto por Charbonneau (2004, p.13). Ressaltando que o objetivo prover um guia para ajudar na elaborao do mapeamento especfico de cada empresa.

4.3.1 Processos de Gerncia de Integrao

Segundo o mostrado na tabela anterior, a rea Integrao envolve muitas disciplinas dentro do RUP e isto acontece pela importncia que esta rea possui dentro de um projeto, a coordenao de diversos componentes. A seguir, o mapa da Gerncia de Integrao (Figura 10).

50

1A

**

***

Iniciao do Projeto; Iniciao das Interaes; Desenv. dos Casos de Negcio;

Iniciao [1A] Gerncia de Projetos 1B Desenv. Plano de Resoluo de Problemas;

Desenv. do Escopo Preliminar

[1B] Planejamento das Fases e Interaes; Desenv. Plano de Interaes; Desenv. Plano de Aceitao; Composio Plano Desenv. Software; Desenv. Casos de Negcio; Monitorao da Situao; Relato da Situao; Agendamento e Distribuio do Trabalho; Tratamento de Problemas e Excees; Monitorao da Situao; Relato da Situao; Tratamento de Problemas e Excees; [1E] Planejamento das Fases e Interaes; Desenv. Plano de Interaes; Desenv. Plano de Aceitao; Composio Plano Desenv. Software; Desenv. Casos de Negcio; Relato da Situao; Estimativa de Interaes;

1C [1C]

Desenv. do Plano de Projeto

1D [1D]

Execuo do Plano de Projeto

1E

Monitorao e Controle do Trabalho

1F

Controle Integrado de Mudana

[1F]

1G

Fechamento do Projeto

Estimativa de Interao; Preparao para o trmino da Fase; Preparao para o trmino Projeto; [1G]

*Processo de uma rea do PMBOK; **Disciplina do RUP; ***Grupo de atividades do RUP;

A figura continua a seguir.

51

Desenv. da Viso;

[1A] Anlise de Requisitos Desenv. do Plano de Gerncia de Requisitos; Desenv. da Viso; Definio de Atores e Casos de Uso; Detalh. dos Caso de Uso; Detalh. Dos Requisitos; Coleta do Vocabulrio; Desenv. da Viso;

[1B]

[1C] Todas as atividade;

[1D] Todas as atividade;

[1E] Desenv. da Viso;

[1F] Desenv. do Plano CM;

Gerncia de Configuraes e Mudanas

[1B] Todas as atividades, principalmente as: Submisso de Pedido de Mudanas;e Atualizao de Pedido de Mudanas; [1D]

Reviso dos Pedidos de Mudanas; Confirmao de Pedidos de Mudanas duplicados ou rejeitados; [1F]

A figura continua a seguir.

52

Desenv. do Plano de Implantao;

Implantao

[1C] Todas as Atividades;

[1D]

Todas as atividade;

[1E] Desenv. do Plano de Implantao;

[1F] Todas as Atividades;

Gerncia de Ambiente

[1C,1D,1E,1F] ] Todas as Atividades;

Modelagem de Negcio

[1D,1E]

Todas as Atividades;

Anlise e Projeto

[1D,1E] Todas as Atividades;

Implementao

[1D,1E] Todas as Atividades;

Testes

[1D,1E]

Figura 10. Mapeamento dos processos de Integrao com Disciplinas do RUP.

53

4.3.2 Processos de Gerncia de Escopo (PMBOK)

A rea Escopo envolve muitas disciplinas dentro do RUP, sendo a segunda mais complexa em termos de combinao, ficando somente atrs de Integrao. A seguir, o mapa de Escopo (Figura 11).

54

2A

Desenv. Plano de Resoluo de Problemas; Desenv. Plano de Gerncia de Requisitos; [2A] Gerncia de Projetos Planejamento de Fases e Interaes; Desenv. Plano de Interaes;

Planejamento do Escopo

2B

Detalhamento do Escopo

[2B] Planejamento de Fases e Interaes; Desenv. Plano de Interaes; [2C]

2C

Criao do WBS

Reviso do ciclo de vida ( Lifecicle Milestone Review ); 2D [2D] Relato de Situao; Estimativa de Interao; Planejamnto de Fases e Interaes; Desenv. Plano de Interaes; [2E] Desenv. do Plano CM;

Verificao do Escopo

2E

Controle do Escopo

Gerncia de Configuraes e Mudanas

[2A,2B] Submisso de Pedido de Mudanas; Atualizao de Pedido de Mudanas; [2E] Desenv. do Plano de Gerncia de Requisitos; Desenv. da Viso; Definio de Atores e Casos de Uso; Detalh. dos Caso de Uso; Detalh. Dos Requisitos; Coleta do Vocabulrio; Reviso dos Requisitos;

Anlise de Requisitos

[2A,2B,2C,2E]

[2D]

Figura 11. Mapeamento dos processos de Escopo com Disciplinas do RUP.

55

4.3.3 Processos de Gerncia de Prazo (PMBOK)

A partir de agora, a deficincia do RUP em relao sobrecarga de preocupaes aglomeradas na disciplina Gerncia de Projeto mais ntida. O mapa a seguir (Figura 12) ilustra uma situao, lembrando que o mesmo apenas tenta guiar os processos das reas do PMBOK com as atividades do RUP onde a ligao e inferncias so mais ntidas e necessrias.
3A Planejamento de Fases e Interaes; Desenv. Plano de Interaes; Desenv. Plano de Resoluo de Problemas;

Definio das Atividades [3A,3B,3E] 3B Gerncia de Projetos

Sequenciamento das Atividades 3C Estimativa de Recursos de Atividades 3D Estimativa de Durao de Atividades 3E Desenvolvimento do Cronograma [3F] 3F Controle do Cronograma Relato de Situao; Estimativa de Interao; [3C,3D] Planejamento de Fases e Interaes; Desenv. Plano de Interaes; Definio Recursos Humanos e Organizao do Projeto; Aquisio de Recursos Humanos;

Figura 12. Mapeamento dos processos de Prazo com Disciplinas do RUP.

4.3.4 Processos de Custo (PMBOK)

Em projetos de desenvolvimento de software, os principais custos esto basicamente relacionados ao esforo (homem/hora), infra-estrutura e aquisies de componentes de software. A seguir o mapa (Figura 13) destes processos nas atividades do RUP.

56

4A

Planejamento de Fases e Interaes;

Estimativa de Custos 4B

Gerncia de Projetos

[4A]

Oramentao de Custos 4C Controle de Custos [4B,4C]

Figura 13. Mapeamento dos processos de Custo com Disciplinas do RUP.

4.3.5 Processos de Gerncia de Qualidade (PMBOK)

Algumas questes crticas em um projeto de desenvolvimento de software esto relacionadas Qualidade. O prprio objetivo desta pesquisa prover benefcios no projeto que por final resultem em eficincia e qualidade. O mapa a seguir (Figura 14) demonstra que o RUP possui um arsenal de atividades muito significativo e completo para um projeto de software.
5A Desenv. Plano de Garantia de Qualidade; Definio do Processo de Monitorao e Controle; Desenv. do Plano de Medio;

Planejamento da Qualidade 5B

Gerncia de Projetos

[5A]

Garantia de Qualidade 5C Gerncia de Configuraes e Mudanas [5B]

Submisso de Pedidos de Mudana; Atualizao de Pedidos de Mudana;

Controle de Qualidade

Submisso de Pedidos de Mudana; Atualizao de Pedidos de Mudana; [5C]

Obs: O processo [5C] tambm est mapeado com todas as atividades relacionadas a Reviso e todas as atividades da disciplina Teste;

Figura 14. Mapeamento dos processos de Qualidade com Disciplinas do RUP.

57

4.3.6 Processos de Gerncia de Recursos Humanos (PMBOK)

O planejamento dos recursos humanos algo complexo e trabalhoso. O grau de envolvimento e competncia das pessoas que pertencem ao contexto do projeto so fatores importantes para o alcance dos objetivos. Geralmente, o departamento responsvel utiliza-se de tcnicas especficas e informaes de sua base de conhecimentos para o desempenho destes processos. O RUP, em si, mostra-se deficiente nestes processos. O mapa a seguir (Figura 15) ilustra um simples mapeamento.
6A Definio Recursos Humanos e Organizao do Projeto;

Planejamento dos Recusos Humanos 6B

Gerncia de Projetos

[6A]

Montagem da Equipe 6C [6B] Desenvolvimento da Equipe [6C,6D] 6D

Aquisio de Recursos Humanos;

Gerncia da Equipe Obs: O processo [6D], no RUP, est associado a responsabilidades e artefatos produzidos.

Figura 15. Mapeamento dos processos de Recurso Humanos com Disciplinas do RUP.

4.3.7 Processos de Gerncia de Comunicao (PMBOK)

Estes processos surgiram basicamente com a necessidade de adequado controle e distribuio de informaes. A medida que os projetos cresciam, sua importncia aumentava dentro do mesmo. So processos essenciais para acompanhar e divulgar dados referentes ao esforo previsto e o realizado. No RUP, estes processos do PMI possuem um mapeamento

58

satisfatrio, devido, principalmente sua prpria natureza. O mapa abaixo (Figura 16) demonstra a situao.
7A Composio do Plano de Desenvolvimento de Software;

Planejamento da Comunicao 7B

Gerncia de Projetos

[7A] Relato de Situao; Estimativa de Interao;

Distribuio da Informao 7C [7B] Definio do Processo de Monitorao e Controle; Relato de Situao; Estimativa de Interao; Preparao para o trmino da Fase; Preparao para o trmino Projeto;

Relato de Desempenho 7D [7C,7D] Controle de Expectativas

Submisso de Pedidos de Mudana; Atualizao de Pedidos de Mudana; Gerncia de Configuraes e Mudanas [7B,7C,7D]

Figura 16. Mapeamento dos processos de Comunicao com Disciplinas do RUP.

4.3.8 Processos de Gerncia de Riscos (PMBOK)

Estes processos visam primordialmente gerenciar riscos que afetam os objetivos do projeto e sua execuo. O RUP, por sua natureza interativa e incremental, possui tambm um bom arsenal de atividades e artefatos para administr-los. O mapa a seguir (Figura 17) demonstrar um guia para os processos de Gerncia de Riscos do PMBOK com as disciplinas do RUP e respectivas atividades.

59

8A

Desenv. do Plano de Gerncia de Riscos;

Planejamento da Gerncia de Riscos Gerncia de Projetos 8B

[8A] Estimativas e Identificao de Riscos;

Identificao dos Riscos 8C [8B,8C,8D,8E,8F] Submisso de Pedidos de Mudana; Atualizao de Pedidos de Mudana; Gerncia de Configuraes e Mudanas [7B,7E,7F]

Anlise Qualitativa de Riscos 8D

Anlise Quantitativa de Riscos 8E

Planejamento de contigncia 8F

Controle e Monitorao de Riscos

Figura 17. Mapeamento dos processos de Riscos com Disciplinas do RUP.

4.3.9 Processos de Gerncia de Aquisies (PMBOK)

Os processos envolvidos nesta rea do PMBOK possuem maior grau de deficincia no mapeamento com disciplinas e atividades do RUP. Estes processos, dentro de um projeto de desenvolvimento de software, so visveis nas compras de componentes de software, ferramentas e infra-estrutura. O mapa a seguir (Figura 18) mostra a situao.

60

9A

Desenvolvimento da Viso;

Planejamento de Aquisies 9B

Anlise de Requisitos

[9A]

Planejamento dos Contratos 9C

Obteno de Propostas 9D [9B,9C,9D,9E,9F] Seleo de Fornecedores 9E

Administrao dos Contratos 9F

Encerramento dos Contratos

Figura 18. Mapeamento dos processos de Aquisies com Disciplinas do RUP. Mostrado o conjunto de mapas que conceitualmente demonstram como as duas metodologias podem interagir (Processos do PMBOK com Disciplinas e Atividades do RUP), importante lembrar que estes servem como um guia, elaborado com base em experincias e conhecimentos previamente adquiridos por equipes de desenvolvimento de software, conjuntamente com seus gestores, que adotaram estas prticas em seus projetos. O PMI possui dentro da sua organizao, colaboradores de diversas reas de aplicao, e a TI no poderia estar de fora. Em breve, muitas das combinaes de conceitos apresentados neste trabalho estaro mais concisas e claras. Charbonneau (2004) em suas pesquisas solidificou esta combinao do RUP com o PMI, mapeando tambm documentos produzidos no PMBOK com artefatos das atividades do RUP, e com esta base, contribuiu para demonstrar que no existem incompatibilidades ou contradies entre os dois padres.

61

QUALIDADE EM PROJETOS DE SOFTWARE

5.1

Fundamentos

At ento, muito se citou sobre qualidade, inclusive uma das justificativas do trabalho em mostrar a possibilidade de combinar o PMBOK com o RUP melhorar a qualidade em um projeto de desenvolvimento de software, seja em seus processos, seja em seus produtos. Portanto, conveniente discutirmos um pouco sobre esse assunto, falando de seus conceitos, sua importncia, metodologias e padres. Todos os estudos dentro da Engenharia de Software geralmente possuem como meta a produo de software com alta qualidade e esta realidade saiu das fronteiras acadmicas proporcionadas pelas grandes empresas e institutos que visionam o progresso nesta disciplina. Hoje, falar de alta qualidade falar de resultados satisfatrios e comprovados mediante todo o seu contexto problemtico ao qual uma atividade foi inserida. A qualidade passou a ser um requisito essencial, a assumir valor competitivo, a direcionar esforos, a decidir rumos tecnolgicos, a determinar passos do mercado e at mesmo a determinar marcos dentro de vrias cincias. Ento, qual venha a ser o significado de Qualidade. Segundo Amora (2003), qualidade propriedade especfica ou condio natural que caracteriza uma coisa... e isto

naturalmente nos induz a procurar atributos em um objeto em anlise para que possamos mensur-los e compar-los com padres previamente conhecidos. Entretanto, discutir o termo Qualidade de Software aprofundar certos conhecimentos e abstrair outros, devido a natureza deste produto ser essencialmente intelectual.

62

5.2

Qualidade de Software

Iniciando a discusso sobre a qualidade do produto software, ser definido o conceito de Qualidade de Software. Segundo SWEBOOK(2004)29, autores e organizaes tm definido este conceito de diversas formas. Para Humphrey (1989), este conceito est relacionado ao alcance de excelentes nveis de usabilidade , enquanto que a IBM e a Baldrige criaram os termos qualidade dirigida ao mercado e qualidade dirigida ao consumidor ,

respectivamente, referenciando com o grau de satisfao envolvido. A definio mais recente foi provida da ISO9001-00 (ISO, 2000), o grau que um conjunto de caractersticas A equipe de

intrnsecas satisfazem os requisitos . Segundo PMBOK (2002, p.96),

gerenciamento do projeto deve tomar cuidado para no confundir qualidade com funcionalidade . No projeto de desenvolvimento de software, a qualidade do produto est fundamentada principalmente nos requisitos, o que determinar atravs de mtricas o grau de aceitao do produto mediante o pblico alvo. Outro fator determinante para a qualidade final obtida em um software a qualidade do processo pelo qual o mesmo foi submetido durante o seu desenvolvimento. Temos ento como objeto de discusso a qualidade do produto e a qualidade do processo. Dentro da qualidade do processo temos modelos e critrios que avaliam as capacidades de uma empresa em termos organizacionais e gerenciais. Segundo a SEI (2005), estes modelos alm de estabelecerem uma linguagem comum, prov uma estrutura de priorizao, agrega melhores prticas e permite diagnsticos consistentes e confiveis. Os padres mais conhecidos so os TicKIT30, o ISO9001-00, ISO90003-04. Atualmente, dentro de um modelo baseado em nveis de maturidade, destaca-se o CMM, que tem origem no SEI31 e teus seus conceitos baseados nas idias de Watts S. Humphrey. Os 5 (cinco) nveis de maturidade, que estruturam o CMM, indicam a capacidade do processo e contm reas-chaves do processo (KPA)32 que esto relacionadas s metas a serem alcanadas. Estas KPA s so organizadas em caractersticas comuns33 que por sua vez contm

29 30

SWEBOK Software Engineering Body of Knowledge. Verso 2004. IEEE Computer Society. TicKit Metodologia para melhoria de qualidade de software e suas aplicaes. www.tickit.org. 31 SEI Software Engineering Institute. www.sei.cmu.edu. 32 KPA Key Process Area. 33 Termo tambm conhecido como Common Features .

63

prticas-chaves34 com finalidade de descrever atividades e infra-estrutura. A Figura 19 abaixo ilustra os de uma forma bsica os nveis do CMM.

Figura 19. Nveis do CMM.

Pelo excelente papel que este modelo vem desempenhando e respectivos resultados, a sua evoluo seria inevitvel, foi ento quando a indstria resolveu desenvolver o CMMI, unindo diversos modelos (SW-CMM35, P-CMM36, SA-CMM37, SE-CMM38, IPD-CMM39) para atingir objetivos, Segundo Ahern(2001), estes so: Definio, documentao e utilizao de processo; Desenvolvimento e monitorao de planos de gesto; Clarear papis e responsabilidades; Mensurar tanto o produto como o processo; Planejamento e eficincia no uso de tecnologia; Melhoria continua; Beneficiar a gerncia de projetos em todos os seus requisitos; e Consistncia com a norma ISO/IEC 15504. Em outro plano, mas no independente, temos a qualidade do produto. Neste plano, as necessidades do cliente so mais importantes e determinantes para a qualidade do produto. A
34 35

Termo tambm conhecido como Key Pratices . SW-CMM CMM for Software. 36 P-CMM People CMM. 37 SA-CMM Software Acquision CMM. 38 SE-CMM Software Enginnering CMM. 39 IPD-CMM Integrated Product Development CMM.

64

elicitao dos requisitos funcionais e no funcionais do software a ser desenvolvido deve ocorrer visando a maior satisfao do cliente. A produo de um software adequado somada com a gerncia provida por toda a qualidade do processo, por fim, determinam a alta qualidade do produto. Alm de medidas tcnicas adotadas em projetos de software, segundo o SWEBOK(2004), o IEEE Computer Society e a ACM desenvolveram um papel importante na elaborao de um cdigo de tica e prticas profissionais, atualmente, baseados em 8 (oito) princpios que provm um interessante arcabouo de informaes sobre qualidade de software para ajudar engenheiros de software em seus projetos.

5.3

Qualidade de Software com PMBOK e RUP

Depois de mostrada uma viso bsica de Qualidade de Software, interessante compreender que expectativas podem ser geradas a par da utilizao da integrao do PMBOK com o PMI em termos de qualidade. Para no prolongar a discusso sobre vrios assuntos, os modelos CMM e CMMI sero usados como demonstrao. A escolha foi feita basicamente devido a grande repercusso no mercado atual deste modelo e possveis novos avanos. A anlise simplificada apresentada considerar apenas o segundo nvel de maturidade da empresa, visto que o primeiro nvel considerado inicial, ad hoc e sem KPAs. Neste nvel, inicia-se a necessidade predominante de estabelecer um gerenciamento eficaz do projeto de software e as polticas organizacionais passam a orientar os projetos estabelecendo processos de gerenciamento, segundo Jaeger & Bocoli (2004). Em adaptao ao trabalho de Jaeger & Bocoli (2004), uma relao inicial proposta, ilustrada na Figura 20, seria:

65

Figura 20. Qualidade mapeada na integrao do PMBOK e RUP.

Esta relao, apesar de simplificada, j retrata alguns passos que podem ser desempenhados em benefcio de qualidade. Visualizar em detalhes essa relao complexo e no parte do escopo deste trabalho, porm, j podemos encontrar um mapeamento do RUP com o CMMI na SEI. O importante ter em mente que em um projeto de desenvolvimento de software, a escolha de boas metodologias e modelos empiricamente garante excelncia em qualidade, tanto em processo, como em produto. Como todo o processo de capacitao de uma empresa mediante os critrios de avaliao do CMM/CMMI so evolutivos, essa integrao de PMBOK e RUP com o KPAs do CMM/CMMI uma semente germinadora de maiores benefcios para nveis superiores (CMM) e essa inter-relao tende a crescer com novos KPAs introduzidos no processo de evoluo da empresa em prol de melhor maturidade organizacional na cadeia produtiva do software. Vale ressaltar que, com a integrao do CMM com novos modelos para a elaborao do CMMI, os novos KPAs introduzidos passaro a ter grande relao com as demais reas do PMBOK.

66

Estudo de Caso: SERPRO-PA

6.1

Consideraes Iniciais

Mediante a apresentao dos assuntos abordados e na tentativa de concretizar o relacionamento das questes discutidas, sendo a principal delas a combinao do PMBOK com o RUP, um estudo de caso foi realizado na empresa SERPRO-PA (Servio Federal de Processamento de Dados Sede Par). Os critrios da escolha esto baseados no papel que a

mesma possui perante o mercado, nos objetivos em termos de qualidade em TI e no carter contributivo para pesquisas, com capacidade de fornecer informaes importantes para o desenvolvimento deste estudo. Atualmente,
O Servio Federal de Processamento de Dados (SERPRO) a maior empresa pblica de prestao de servios em tecnologia da informao do Brasil. Foi criado pela Lei n 4.516, de 1 de dezembro de 1964, para modernizar e dar agilidade a setores estratgicos da administrao pblica. uma empresa vinculada ao Ministrio da Fazenda e cresceu desenvolvendo programas e servios que permitiram maior controle e transparncia sobre a receita e os gastos pblicos. Consolidou-se, ao longo desses anos, aprimorando tecnologias adotadas por diversos rgos pblicos federais, estaduais e municipais, e incorporadas vida do cidado brasileiro. (Fonte: www.serpro.gov.br, 2005)

Dentro das premissas do SERPRO, encontramos conceitos relacionados gesto e qualidade, nas linhas de negcio, encontra-se o desenvolvimento de solues e dentro deste contexto, somado com a realidade de possuir inmeros e importantes clientes (Governo), esta empresa certamente uma candidata a possuir um excelente arcabouo de aes e informaes visando o progresso em questes associadas Gerncia de Projetos de Software. Como metodologias de coleta de informaes, foram utilizadas pesquisas bibliogrficas, entrevista e questionrio (anexo III). A empresa foi provida de livre julgamento para escolher, limitar as informaes ou desconsiderar qualquer tpico ou questo, relacionados na entrevista e questionrio. Os dados foram gentilmente coletados e discutidos sob origem do Sr. Ticiano Monterio, Gerente de Projetos em TI, em data de 09 de dezembro de 2004.

67

6.2

Anlise de dados

Com as informaes coletadas, alguns pontos importantes foram percebidos sendo divididos em duas categorias: a) Administrativas: referentes s informaes pertinentes a normas, exigncias e metas no mbito empresarial; e b) Tecnolgicas: estas so pertinentes a normas, processos de desenvolvimento de software, metodologias, ferramentas e metas em um mbito mais restrito, o da Tecnologia de Informao. Dentre as informaes administrativas coletadas, o principal dado est relacionado utilizao de prticas do PMBOK, que apesar de fase de implantao, resultados relevantes j foram alcanados, demonstrando que de fato estas prticas so importantes dentro do mercado atual seguido de suas exigncias. A prtica de gerncia de projetos suportada por ferramentas de distribuio e regulao de informaes, como correio eletrnico e GED (Gerenciador Eletrnico de Documentos). No intuito de aprimorar o fluxo de informaes dentro da empresa, permitindo assim que importantes passos sejam dados em direo gerncia de projetos, estuda-se a adoo de uma ferramenta para beneficiar os processos existentes. Nota-se que j existe certo grau de maturidade dentro dos processos de gerncia. A preocupao com uma metodologia formal para administrar projetos dentro de uma empresa e o controle integrado de aes so grandes passos para o desempenho de atividades com excelncia e qualidade, as quais representam as principais metas administrativas dentro do ramo em que atua. J em relao as informaes tecnolgicas coletadas, dados muito importantes demonstram a preocupao com o processo de desenvolvimento de software, como o grau de investimento, normas implantadas, ferramentas e treinamentos. O destaque entre esses dados a utilizao de um processo de software, o PSDS (Processo SERPRO de Desenvolvimento de Solues). Este processo uma instncia do RUP e foi completamente customizado de acordo com os componentes estratgicos e necessidades da empresa. O PSDS tem como suporte a utilizao da UML, Anlise por Ponto de Funo, Anlise por Caso de Uso e Anlise Estruturada, como prticas para atender a peculiaridades de diversos projetos.

68

Apesar dos principais obstculos para a efetiva implantao e, consequentemente, evoluo deste processo na empresa estar relacionados ao contexto de capacitao pessoal, investimentos so constantemente feitos nesta rea para manter as equipes alinhadas com conhecimentos emergentes no mercado.

6.3

Resultados da pesquisa

Retrata-se a realidade de grandes corporaes de acordo com novas necessidades do mercado, onde existe a constante necessidade de agregar valores ao processo gerenciais e aos processos especficos do produto desenvolvido. De acordo com o propsito do trabalho, o SERPRO-PA utiliza-se de excelentes metodologias de mercado como o PMBOK e o RUP. Seu desempenho mediante seus objetivos e metas , certamente, uma demonstrao dos benefcios que a combinao destes conceitos pode vir a trazer. Um fator muito importante, que isso mostra que empresas brasileiras j possuem experincias necessrias para se adequar s exigncias mercadolgicas mundiais, e o SERPRO um grande exemplo desta realidade. Como esta empresa tem o ramo onde uma de suas reas de negcio o desenvolvimento de software, fica mais ntida a necessidade de integrao e mapeamento entre as atividades gestoras e estratgicas da empresa e as atividades do setor competente para as solues em TI. O ntido interesse em eficincia e qualidade (CMM) nos processos e produtos, fizeram com que a empresa investisse no ITIL40 para gesto de recursos em TI, somado com a existncia de um processo de desenvolvimento de software bem definido e consolidado, que por sua vez baseado no RUP, e encontra-se tambm em fase de implantao uma poltica de gerncia de projetos baseada no PMBOK, a integrao entre esses processos (gerncia e produtos) de interesse da empresa e h esforos para esse caminho.

40

ITIL - IT Infrastructure Library. www.itil.org.

69

CONCLUSO

No decorrer do trabalho, foram inicialmente abordados conceitos importantes para o desenvolvimento da pesquisa. Compreender a disciplina Gerncia de Projetos e relacionar as reas e processos envolvidos foi necessrio para o objetivo da pesquisa, tendo como base, o PMI e todo conhecimento concretizado no PMBOK. Posteriormente, uma breve discusso foi feita sobre Processos de Desenvolvimento de Software e com o suporte do RUP, foram apresentadas prticas importantes e j reconhecidas pelo mercado. Ressalvadas as necessidades do mercado mediante o contexto de Gerncia de Projetos de Software, verificou-se a exiquidade da combinao das duas metodologias para atuar dentro de empresas, com o intuito de relacionar os processos gerenciais e processos especficos do produto para obteno de melhor qualidade e efetividade em software. De um lado o PMBOK, atuando nos processos gerenciais na tentativa de administrar e controlar inmeros fatores estratgicos, de outro, o RUP, garantindo a formalidade e desempenho das atividades do desenvolvimento de software. Como dentro do objetivo o termo Qualidade de Software foi apresentado, uma abordagem simples foi feita para demonstrar alguns padres, o foco dessa demonstrao foi o CMM e o CMMI, devido principalmente s repercusses mercadolgicas. Em um estudo de caso, apesar de dificuldades relacionadas em encontrar uma empresa na regio norte com preocupao tcita e emergente com a formalizao de processos e melhorias significativas no produto software, serviu para mostrar que a realidade em nvel brasileiro favorvel para o desempenho de pesquisas associadas implantao do PMBOK e do RUP e, consecutivamente, a integrao de seus processos e artefatos. importante entender que o mundo est em constante evoluo e com isso, novas tendncias e necessidades surgem. Para isso, a Gerncia de Projetos est em constante mudanas para estar sempre em conforme para atend-las, um exemplo o avano nos estudos de gerenciamento de mltiplos projetos. Para trabalhos futuros, pode-se tentar relacionar os conceitos abordados com novos temas, como: ERP41, Gesto de Conhecimentos, Balanced Score Card, entre outros. Outro ponto interessante o desenvolvimento de plugins ou modelos para realizar o mapeamento em ferramentas j existentes no mercado tanto para o PMBOK quanto para o RUP. Um

41

ERP Enterprise Resource Planning.

70

progresso significativo seria o melhor mapeamento dos 3 (trs) conceitos PMBOK, RUP e CMMI, abordando principalmente seus processos. Pode-se tambm realizar comparaes de desempenho em relao a outros processos gerenciais e orientados ao produto.

71

REFERNCIAS BIBLIOGRFICAS

AMORA, Soares. Dicionrio da Lngua Portuguesa. 17. ed. So Paulo: Saraiva. 2003.

AHERN,D.M., Clouse,A, Turner,R. CMMI Distilled: a Practical Introduction to Integrated Process Improvement, Addison-Wesley, 2001 CHARBONNEAU, Serge. Software Project Management - A Mapping between RUP and the PMBOK. Site disponvel em <http://www.rational.com>. Acesso em 11 de dezembro de 2004.

COTTRELL, Bill. Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOK. Site disponvel em <http://www.rational.com>. Acesso em 11 de dezembro de 2004.

DORFMAN, M; THAYER, R. H. Software Engineering. (Vol. 1 & vol. 2), IEEE Computer Society Press, 2002.
FUCHS, Sid. New Dimensions of Project Management. Site disponvel em

<http://www.therationaledge.com/content/may_01/f_projman_sf.html>. Acesso em 25 de dezembro de 2004.

IEEE COMPUTER SOCIETY. Guide to the Software Engineering Body of Knowledge (SWEBOK Guide). 2004, p.202.

ISO 9001:2000, Quality Management Systems- Requirements: ISO, 1994.

JAEGER NETO, J. I .N.; BOCOLI, F. S. Gerncia de Projetos de Software CMM & PMBOK. Disponvel em: <http://www.pmirs.org/Documentos/GerenciaProjetosSoftwareCMM_PMBOK.pdf>. Acesso em 21 de dezembro de 2004.

KERZNER, H. Project Management A Systems Approach to Planning, Scheduling, and Controlling, New York NY, John Willey & Sons, 2001.
KOONTZ, H. e O DONNEL,C; (1980). Os Princpios de Administrao: Uma Anlise das Funes Administrativas. So Paulo, Pioneira.

72

Kroll, Per; KRUCHTEN, Philippe. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Pittsburgh: Addison-Wesley, 2003.

MARTINS, Jos Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML. 1. ed. Rio de Janeiro: BRASPORT, 2004.

MARTINS, L.; (2003) Gesto Profissional de Projetos. Disponvel em <http://www.ietec.com.br/ietec /techoje/techoje/gestaodeprojetos/2003/10/10/2003_10_10_0 003.2xt/-template_interna>. Acessado em 01/04/2004.
PAULK, M. C. et al. The Capability Maturity Model Guidelines for Improving the Software Process. Pittsburgh: Addison Wesley, 1994. PRESSMAN, Roger S. Engenharia de Software. Rio de Janeiro: McGraw-Hill, 2002. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide): 3.ed. 2004, p.388. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK Guide): 2.ed. 2000, p.177. PROJECT MANAGEMENT INSTITUTE, Chapter MG. Project Management Body of Knowledge, Traduo livre v1.0. Minas Gerais: PMI-MG, 2000, p.159. ROYCE, Walker. Achieving Better Software Results: A Project Management Perspective. Site disponvel em <http://www.rational.com>. Acesso em 01 de dezembro de 2004. SOTILE, Mauro. Um novo paradigma em Gerenciamento de Projetos. Site disponvel em <http://www.pmirs.org> .Acesso em 23 de dezembro de 2004.

THAYER, Lee. Princpios de comunicao na administrao: comunicao e sistema de comunicao na organizao da administrao e relaes internas. Atlas. 1972.

TOLEDO, Ricardo Cortez. Integrao do RUP e do PMI no desenvolvimento de projetos de software: O Caso Escritrio de Projetos da Academia Nacional de Polcia. 2004, 103f. Dissertao (MBA em Administrao Estratgica de Sistemas de Informao) - Fundao Getlio Vargas FGV, Braslia.

VARGAS, Ricardo. Novas tendncias em Gerenciamento de Projetos. Site disponvel em <http://www.aec.com.br>. Acesso em 20 de dezembro de 2004.

73

WEST, David. Planning a Project with the Rational Unified Process. Site disponvel em <http://www.rational.com>. Acesso em 22 de dezembro de 2004.

74

ANEXOS

75

DIAGRAMA DE INTERAO EM ALTO NIVEL DOS GRUPOS DE

PROCESSOS DO PMBOK. (PMBOK, 2004, p.42).

76

II

MAPEAMENTO GRUPO DE PROCESSOS POR REAS DE CONHECIMENTO.

(PMBOK, 2004, p.70).

77

III QUESTIONRIO (ESTUDO DE CASO).

PESQUISA TCNICO-ADMINISTRATIVA GERNCIA DE PROJETOS DE SOFTWARE

ESTUDO DE CASO SERPRO-PA (SERVIO FEDERAL DE PROCESSAMENTO DE DADOS SEDE PAR)

Esta pesquisa acadmica e prover subsdios que serviro como estudo de caso para o Trabalho de Concluso de Curso de Ricardo Carvalho de Souza, sob matrcula 0008801501, graduando em Bach. em Cincia da Computao pela Universidade Federal do Par, e assim sendo, no ter fins comerciais ou infligir qualquer norma ou procedimento adotados pela

Empresa/Instituio em questo.

78

PESQUISA TCNICOADMINISTRATIVA GERNCIA DE PROJETOS DE SOFTWARE SERPRO PA SEDE PAR

SERVIO DE PROCESSAMENTO DE DADOS

As informaes contidas neste questionrio so relevantes ao desenvolvimento de uma pesquisa que servir como suporte para a elaborao de um estudo de caso. As mesmas visaro obordar fatores relacionados to somente Gerncia de Projetos de Software. A empresa/instituio est provida de livre julgamento para escolher, limitar as informaes ou desconsiderar qualquer tpico ou questo, relacionados neste questionrio. Dados coletados e discutidos, sob origem de: Sr. Ticiano Monterio, Gerente de Projetos em TI, em data de 09 de dezembro de 2004.

DADOS DA EMPRESA

1. 2. 3. 4. 5. 6. 7. 8.

Ramo: Tecnologia da Informao e Comunicao Atividade: Desenvolvimento de Sistemas Principal tipo de cliente: Governo Nmero total de funcionrio: (estimativa). 30 Nmero de funcionrio em TI, incluindo todas as classes: (estimativa). 30 Nmero de gerentes de projetos de software: 4 Nmero de gestores, scios ou parceiros: Mdia anual de Projetos em TI: (qualquer tipo de projeto). 15

ADMINISTRAO 1. A empresa/instituio possui normas e procedimentos para gerenciar projetos, sejam

eles aplicveis em software ou no? Quais? Por quais motivos eles foram escolhidos? Atualmente eles suprem todas as necessidades? Resposta: Sim. Para projetos de software, o SERPRO adota o PSDS(Processo Serpro de Desenvolvimento de Solues) que uma instncia do RUP. Para os demais projetos adota as orientaes do PMI por meio de uma poltica de gesto de projetos da empresa (em fase de implantao). 2. Nos projetos, exige-se que as informaes sejam de circulao de mbito global,

envolvendo no somente profissionais de TI, mas tambm diretorias de outros setores bem

79

como parceiros? Qual meio adotado para tal feito? Caso no possuam, pensam em adotar algum? Qual? E Por qu? Resposta: O SERPRO trabalha fortemente com correio eletrnico e com uma ferramenta desenvolvida internamente para a gesto de correspondncias formais(prestando alguns servios no disponveis no correio eletrnico tradicional). Estuda-se a adoo de uma ferramenta que permita um melhor controle do fluxo de informaes, inclusive, com uma base centralizadas de projetos. 3. Quais reas abaixo relacionadas so de preocupao desta empresa/instituio e que

mtodos, metodologias ou ferramentas so usados para gerenci-las dentro de um projeto? a) b) c) d) e) f) g) h) i) 4. 5. Integrao: Escopo: Recursos Humanos: Riscos: Qualidade: Tempo: Comunicao: Custo: Aquisies: Quais os principais obstculos encontrados na maioria dos projetos desenvolvidos? Quais as principais metas da empresa/instituio?

Resposta: Na rea de desenvolvimento de aplicaes certificao CMM. Atualmente 7 unidades de desenvolvimento da empresa j foram certificadas com o nvel 2 e j caminham para o nvel 3. As demais unidades tm planos de aes concretas visando o nvel 2. Ns, em Belm, devemos nos certificar ainda este ano.

TECNOLOGIA DE INFORMAO 6. A empresa/instituio possui normas e procedimentos para gerenciar projetos de

desenvolvimento de software? Quais? Por quais motivos eles foram escolhidos? Atualmente eles suprem todas as necessidades? Resposta: Como dito usamos o PSDS. H 3 anos no tnhamos um processo nico na empresa, cada equipe usava o seu prprio. verdade que outras tentativas j foram realizadas, mas sem sucesso. Alguns colegas lembram que no tempo onde a plataforma era toda centralizada em mainframes, o processo era superorganizado!. A empresa notando a necessidade de uniformizao de procedimentos, e entendo que o desenvolvimento de

80

aplicaes o foco da nossa organizao, criou o Programa de Modernizao do Desenvolvimento(PMOD) e investiu R$ 34.000.000,00, em treinamentos, ferramentas e consultoria. O resultado que hoje temos um processo j institucionalizado com resultados bem importantes. No vejo como esta iniciativa no prosperar e garantir o futuro de nossa empresa. 7. Existe entre este processo de desenvolvimento de software, acima abordado, e as

normas e procedimentos da administrao alguma forma de interao? Qual? Caso ela no exista, ela necessria? E Por qu? Resposta: A empresa criou normas/polticas para cada rea chave do processo CMM. Desta forma, agora, norma funcional a utilizao das prticas do CMM. 8. Os profissionais so capacitados para seguir tal processo de desenvolvimento de

software? Este processo compulsrio ou simplesmente fornece um guia de boas prticas? Caso seja compulsrio, o que o garante? Resposta: Todos os empregados envolvidos com o processo so treinados por instrutoria interna ou externa. Existe uma grade mnima que deve ser seguida por todos os empregados. A grade mnima de treinamentos para o nvel 2 do CMM de 200h de treinamentos. 9. Quais mtodos, metodologias ou ferramentas so usados para auxiliar o processo de

desenvolvimento de software e por que elas foram adotadas? Resposta: Usamos o PSDS que baseado no RUP. A metodologia e ferramentas so definidas e descritas no processo. Usamos a UML como notao, anlise de pontos por funo, anlise de casos de uso, temos a opo de usar anlise e projeto orientados a objetos ou estruturados, dependendo da familiaridade da equipe envolvida, entre outras tcnicas. 10. De regra geral, todos os objetivos de um projeto de desenvolvimento de software so

alcanados, sejam eles referentes a prazo, custo ou at mesmo recursos utilizado? Se for possvel, cite em termos de percentual. Resposta: No temos o percentual, mas bastante alto, mais de 90%. 11. Quais os maiores obstculos encontrados hoje para que maiores e melhores resultados

sejam obtidos dentro da empresa/instituio em termos de desenvolvimento de software? Resposta: Acredito que um bom processo de desenvolvimento fortemente baseado nas pessoas que fazem este desenvolvimento. Pessoas bem treinadas fundamental. Temos um corpo funcional bem treinado, mas sempre vale a pena investir mais. Outro ponto fundamental a conscincia da necessidade de melhorar sempre e isso nossa empresa tem. 12. Quais os planos de melhoria dentro do setor de TI que provero a superao destes

obstculos?

81

Resposta: H uma poltica continua de treinamentos. Mantendo as equipes alinhadas com o que existe de mais novo no mercado. Tambm h abertura para o autoestudo, fundamental para o desenvolvimento individual e do grupo. 13. Existem planos para a rea de Qualidade em Software? Quais as metas e como se

pretende alcan-las? Resposta: Existe uma rea bem estruturada de Garantia de Qualidade de Software, seguindo todas as prticas preconizadas pelo CMM. Cada unidade de desenvolvimento tem sua estrutura de gestores e consultores de GQS, realizando as auditorias e registrando todas as ocorrncias em um sistema prprio, permitindo a consolidao de indicadores e visibilidade para toda a empresa. Posso afirmar que esta rea fundamental e talvez a mais importante para institucionalizao de um novo processo em uma empresa. Apenas com a vigilncia continua e identificao da necessidade de melhorias, um processo pode ser implantado e aprimorado continuamente. 14. A empresa/instituio j se utilizou de conhecimentos abordados pela combinao do PMI (Gerncia de Projetos) e RUP (Processo de Desenvolvimento de Software)?

PMBOK

O que achou? Continua usando? Existem planos para a utilizao ou para a melhora de todos os processos da empresa/instituio com esta combinao? Resposta: Encontra-se em fase de implantao a Poltica de Gerncia de Projetos da Empresa baseada no PMBOK. A idia que todas as aes da empresa sejam tratadas e controladas como projetos, seguindo as orientaes do PMI. Hoje apenas a parte de projetos de software assim tratada. Existe um programa de incentivos a certificao PMP. 15. Caso tenha usado a combinao acima, quais os principais resultados obtidos? Caso

seja possvel, cite em termos de nmero tambm.

CONSIDERAES FINAIS Espao com a finalidade de ressaltar ou abordar qualquer fator relevante para a empresa/instituio que no tenha sido abordado pelo questionrio ou at crticas e sugestes para a pesquisa. A empresa est em fase de implantao do modelo ITIL para gesto de Recursos de TI; A empresa est implantando as prticas do PMBOK na empresa como um todo. Como a rea de desenvolvimento j utiliza um processo bem definido(PSDS) tem muito interesse na integrao do RUP com o PMBOK.

82

IMPORTANTE Deseja que os resultados obtidos sejam divulgados na pesquisa sob condies de anonimato (ex: Empresa/Instituio X )? R: No h restries a utilizao das informaes prestadas.

Agradecemos a compreenso e a colaborao por ajudar na pesquisa. Aps a formulao da dissertao, o texto ser submetido anlise do responsvel por fornecer tais informaes para assegurar que esta prtica no desfavorea ou comprometa a empresa/instituio.

83

ANEXO IV

TCNICAS GERENCIAIS (ALGUNS EXEMPLOS ABORDADOS)

PDM Precedence Diagram Method. (PMBOK, 2004, p. 131).

ADM

Arrow Diagram Method. (PMBOK, 2004, p. 132).

84

CPM Critical Path Method. (SMARTDRAW Software).

PERT Program Evaluation and Review Technique. (SMARTDRAW Software).

85

Desenvolvimento de Cronogramas

Gantt e Marcos (PMBOK, 2004, p. 150).

86

DT

Decision Tree (PMBOK, 2004, p. 258).

CRS

Cost Risk Simulation. (PMBOK, 2004, p. 259).