UMA ABORDAGEM PRÁTICA DO GERENCIAMENTO DA SUBCONTRATAÇÃO PARCIAL PARA O
DESENVOLVIMENTO DE SOFTWARE
André Jorge Dias de Moura
TESE SUBMETIDA AO CORPO DOCENTE DA COORDENAÇÃO DOS PROGRAMAS DE PÓS-GRADUAÇÃO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM ENGENHARIA CIVIL.
Aprovada por:
_______________________________________________________
Prof. Nelson Francisco Favilla Ebecken, D.Sc
_______________________________________________________
Prof. Alexandre Gonçalves Evsukoff, Dr.
_______________________________________________________
Prof. Antonio César Ferreira Guimarães, D.Sc
RIO DE JANEIRO, RJ - BRASIL MARÇO DE 2004
MOURA, ANDRÉ JORGE DIAS DE
Uma abordagem prática do gerenciamento da subcontratação parcial para o desenvolvimento de software [Rio de Janeiro] 2004.
XIV, 164 p. 29,7 cm (COPPE/UFRJ, M. Sc., Engenharia Civil, 2004)
Tese - Universidade Federal do Rio de Ja- neiro, COPPE
1. Adoção de subcontratação parcial 2. Subcontratação com o processo iterativo 3. Subcontratação no Brasil
I. COPPE/UFRJ II. Título (série)
Dedico esta tese a minha mãe, que durante sua passagem por este mundo soube utilizar seu conhecimento com sabedoria.
Março de 2004
O meu agradecimento primeiro é feito a minha esposa Gorette e aos meus filhos Ana Carolina, Patrícia e André, pela compreensão que tiveram durante todo o tempo que necessitei afastar-me para o isolamento.
Que bom ter conhecido o Professor Nelson Francisco Favilla Ebecken. Sem ele esta tese não teria se materializado. Meu agradecimento como orientador de conhecimentos técnicos e humanos.
Ao amigo Professor José Luiz dos Anjos Rosa, meu agradecimento pela ajuda espontânea quando precisei.
Aos amigos da Companhia Brasileira de Petróleo Ipiranga, meu agradecimento pelo apoio recebido.
Aos parentes e amigos que direta ou indiretamente torceram por mim.
Março de 2004
Resumo da Tese apresentada à COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (M. Sc.)
UMA ABORDAGEM PRÁTICA DO GERENCIAMENTO DA SUBCONTRATAÇÃO PARCIAL PARA O
DESENVOLVIMENTO DE SOFTWARE
André Jorge Dias de Moura
Março/2004
Orientador: Nelson Francisco Favilla Ebecken
Programa: Engenharia Civil
Este trabalho pretende analisar a adoção de subcontratação parcial com empresas que desenvolvem software utilizando o processo iterativo. Através das bases teóricas do RUP e do PMBOK, se faz uma proposição de um modelo de gerenciamento de subcontratação de software que suporta este tipo de processo. Também são mostrados alguns cenários possíveis de subcontratação parcial onde a iteração é praticada simultaneamente pela contratante e subcontratada. Por último, se apresenta a experiência obtida por uma empresa com a implantação do processo iterativo e com a utilização do modelo de gerenciamento de subcontratação de software.
Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M. Sc.)
A PRACTICAL APPROACH OF THE MANAGEMENT OF THE PARTIAL SUBCONTRACT FOR
SOFTWARE DEVELOPMENT
André Jorge Dias de Moura
March/2004
Advisor: Nelson Francisco Favilla Ebecken
Department: Civil Engineering
The objetive of this study is to analyse the partial subcontract for third parties which develop interactive process softwares. Considering the RUP and PMBOK theoretical base, it is proposed a management model of subcontract for a software that supports this type of process. Also, it presents some possible alternatives of partial subcontract with a simultaneous interaction between the client and the supplier. Then, it shows an example of a company experience after the implementation of an interactive process and the use of a management model of software subcontract.
ÍNDICE DO TEXTO
Resumo ... v
Abstract ...…... vi
1. INTRODUÇÃO...…... 01
1.1 OBJETIVO………...…....…...….. 01
1.2 METODOLOGIA………..…...…...…. 02
1.3 CONTRIBUIÇÃO DO TRABALHO………... 02
1.4 ORGANIZAÇÃO DA DISSERTAÇÃO DE TESE………. 02
2. ENQUADRAMENTO TEÓRICO...…... 05
2.1 RATIONAL UNIFIED PROCESS (RUP)...…....…...….. 06
2.2 CAPABILITY MATURITY MODEL (CMM) ...…...…. 26
2.3 PROJECT MANAGEMENT BODY OF KNOWLEDGE……….... 30
3. MAPEAMENTO DO RUP NAS EMPRESAS DO BRASIL... 36
3.1 METODOLOGIA………....……….….……….... 36
3.2 APRESENTAÇÃO DOS RESULTADOS...….….……….... 38
3.3 RESUMO DOS RESULTADOS...…….……….... 64
ÍNDICE DO TEXTO
4. SUBCONTRATAÇÃO PARCIAL COM O RUP... 66
4.1 HOMOLOGAÇÃO DE EMPRESAS DESENVOLVEDORAS DE SOFTWARE……...…...……….... 67
4.2 ADOÇÃO DA SUBCONTRATAÇÃO...……....…….... 73
4.3 CENÁRIOS DE SUBCONTRATAÇÃO...…….……….... 80
5. GERENCIAMENTO DE SUBCONTRATAÇÃO... 92
5.1 MÉTRICAS...………....………..……….... 92
5.2 MEDIÇÃO DE QUALIDADE...…...……….... 97
5.3 ARTEFATOS UTILIZADOS...………... 99
5.4 PRINCIPAIS PAPÉIS UTILIZADOS NA SUBCONTRATAÇÃO. 107 5.5 PROCESSO DE SUBCONTRATAÇÃO DE SOFTWARE... 109
5.6 PRÁTICA DA SUBCONTRATAÇÃO DE SOFTWARE NA PETRÓLEO IPIRANGA...………... 125
6. CONCLUSÃO... 133
6.1 RESULTADO DA PESQUISA DE CAMPO...…....…...….. 134
6.2 SUBONTRATAÇÃO DE SOFTWARE…...…...…...…. 136
ÍNDICE DO TEXTO
6.3 CONSIDERAÇÕES FINAIS...………... 139
REFERÊNCIAS BIBLIOGRÁFICAS... 141
ANEXO I - GLOSSÁRIO... 144
ANEXO II - QUESTIONÁRIO... 157
ÍNDICE DE FIGURAS
1.01 ESTRUTURA DA DISSERTAÇÃO DE TESE... 04
2.01 CICLO DE VIDA CASCATA... 08
2.02 RISCO NO CICLO DE VIDA CASCATA... 08
2.03 EXEMPLO DE CICLO DE VIDA ITERATIVO... 09
2.04 CICLO DE VIDA ITERATIVO... 09
2.05 COMPARAÇÃO DOS CICLOS DE VIDA CASCATA E ITERATIVO... 10
2.06 EXEMPLO DE CASOS DE USO: CAIXA ELETRÔNICO... 12
2.07 ARQUITETURA EM CAMADAS……... 14
2.08 CUSTO DE UM PROBLEMA EM RELAÇÃO AO TEMPO PARA CORRIGI-LO... 16
2.09 ARQUITETURA GERAL DO RUP... 18
2.10 EXEMPLO DE DIAGRAMA DE ATIVIDADES DA DISCIPLINA DE REQUISITOS... 20
2.11 AS FASES E OS MARCOS DE UM PROJETO... 21
2.12 OS CINCO NÍVEIS DE MATURIDADE DO CMM... 27
2.13 RELACIONAMENTO ENTRE OS GRUPOS DE PROCESSO EM CADA FASE………... 32
ÍNDICE DE FIGURAS
3.01 AVALIAÇÃO DO CUSTO ORÇADO... 46
3.02 AVALIAÇÃO DO PRAZO... 46
3.03 AVALIAÇÃO DOS STAKEHOLDERS...…... 46
3.04 AVALIAÇÃO DO NÚMERO DE FUNCIONÁRIOS... 47
3.05 AVALIAÇÃO DO CUSTO DE MANUTENÇÃO DO CICLO DE VIDA
DOS SISTEMAS DESENVOLVIDOS COM O PROCESSO RUP... 47
3.06 AVALIAÇÃO DO ORÇAMENTO PARA PROJETOS SUBCONTRATADOS QUE UTILIZAM O PROCESSO RUP... 48
3.07 UTILIZAÇÃO DO PROCESSO RUP NAS EMPRESAS... 48
3.08 ESTÁGIO DE UTILIZAÇÃO DAS MELHORES PRÁTICAS DO PROCESSO RUP NAS EMPRESAS... 49
3.09 ESTÁGIO DA UTILIZAÇÃO DAS DISCIPLINAS DO PROCESSO RUP NAS EMPRESAS... 50
3.10 PROJETOS DEFINIDOS DE FORMA CLARA... 51
3.11 OS MESMOS PROBLEMAS SE REPETEM SEMPRE... 51
3.12 GERENTES SEM VISÃO REALISTA DO PROGRESSO DO PROJETO 52 3.13 RETRABALHO PARA AJUSTE DE ESCOPO... 52
3.14 CUSTOS ACIMA DO ORÇADO... 53
3.15 ATRASOS NO CRONOGRAMA... 53
3.16 QUALIDADE DEIXANDO A DESEJAR... 53
3.17 ESCOPO DO PROJETO NÃO CUMPRIDO TOTALMENTE... 54
3.18 CANCELAMENTO DO PROJETO... 54
3.19 INSATISFAÇÃO DOS STAKEHOLDERS COM O RESULTADO DOS PROJETOS SUBCONTRATADOS... 55
3.20 DIFICULDADE DOS STAKEHOLDERS PARA CONSENSO NA
DEFINIÇÃO DAS FUNCIONALIDADES... 55 3.21 DIFICULDADE DE COMUNICAÇÃO ENTRE SUBCONTRATADA E EMPRESA... 56 3.22 GERENTES PERDEM A CREDIBILIDADE... 56
3.23 PROCESSO IMPROVISADO PELA EQUIPE PARTICIPANTE
DURANTE O ANDAMENTO DO PROJETO... 57 3.24 PROCESSO ESPECIFICADO E NÃO SEGUIDO COM RIGOR... 57
3.25 COM IMPOSIÇÃO DE DATAS CRITICAS HÁ REDUÇÃO NA
QUALIDADE E NO NÚMERO DE FUNCIONALIDADES... 58 3.26 INSATISFAÇÃO DA ÁREA DE INFORMÁTICA COM O
RESULTADO DOS PROJETOS... 58 3.27 MAU DIMENSIONAMENTO DO ESFORÇO PELA
SUBCONTRATADA E TENTATIVA DE RENEGOCIAÇÃO DO
CONTRATO... 59 3.28 UTILIZAÇÃO DE MÉTRICAS... 59
3.29 TAMANHO DO PROJETO CALCULADO POR QUANTIDADE DE
PONTOS DE FUNÇÃO... 60 3.30 TAMANHO DO PROJETO CALCULADO POR QUANTIDADE DE
CASOS DE USO... 60 3.31 TAMANHO DO PROJETO CALCULADO POR ESTIMATIVA DE
HORAS... 61 3.32 FALTA DE EXPERIÊNCIA DA EMPRESA PARA DESENVOLVER
APENAS PARTES DE UM PROJETO COM A SUBCONTRATADA. 61 3.33 FALTA DE EXPERIÊNCIA DA SUBCONTRATADA PARA
DESENVOLVER APENAS PARTES DE UM PROJETO COM A
EMPRESA... 62 3.34 SUBCONTRATAÇÃO PARA DESENVOLVER O PROJETO
INTEIRO... 62
3.35 SUBCONTRATAÇÃO DA FASE DE INICIAÇÃO SEGUIDA DA SUBCONTRATAÇÃO DAS OUTRAS FASES COM A MESMA
EMPRESA... 63
3.36 SUBCONTRATAÇÃO DA FASE DE INICIAÇÃO SEGUIDA DO ORÇAMENTO DAS OUTRAS FASES COM VÁRIAS EMPRESAS 63 3.37 OUTRAS FORMAS DE SUBCONTRATAÇÃO PARCIAL... 63
3.38 CONTRATAÇÃO DE DETERMINADA QUANTIDADE DE HORAS PARA ACOMODAR O DESENVOLVIMENTO E MANUTENÇÃO DE PROJETOS SOB DEMANDA... 64
4.01 VISÃO GERAL DE UM PROCESSO DE HOMOLOGAÇÃO GENÉRICO... 68
4.02 ARTEFATOS DE COMUNICAÇÃO DIFERENTES... 75
4.03 ARTEFATOS DE COMUNICAÇÃO SEMELHANTES... 75
4.04 ATIVIDADE P ASSOCIADA ÀS FASES DO RUP... 81
4.05 SUBCONTRATAÇÃO PARCIAL A PARTIR DE UM MODELO DE CASOS DE USO... 84
4.06 SUBCONTRATAÇÃO PARCIAL A PARTIR DE UM MODELO DE DESIGN... 86
4.07 SUBCONTRATAÇÃO PARCIAL DE PROGRAMAÇÃO... 89
5.01 VISÃO GERAL DO FLUXO DE SUBCONTRATAÇÃO... 109
5.02 PLANO DE GERENCIAMENTO DE SUBCONTRATAÇÃO... 110
5.03 CONVIDAR EMPRESAS HOMOLOGADAS... 114
5.04 OBTER PROPOSTAS... 116
5.05 SELECIONAR SUBCONTRATADA... 117
5.06 ADMINISTRAR CONTRATO... 120
5.07 ENCERRAR CONTRATO... 123 5.08 IMPLEMENTAÇÃO DO PDSI... 128 5.09 VISÃO GERAL DO FLUXO DE TRABALHO DA
DIVISÃO DE INFORMÁTICA DA PETRÓLEO IPIRANGA... 129
ÍNDICE DE TABELAS
2.01 RELACIONAMENTO DO CMM NÍVEL 2 COM O RUP... 30
2.02 MAPEAMENTO DOS PROCESSOS DE GERENCIAMENTO DE PROJETO EM GRUPOS DE PROCESSOS E ÁREAS DE CONHECIMENTO... 34
3.01 EXPERIÊNCIA PROFISSIONAL EM ENGENHARIA DE SOFTWARE 38 3.02 ATIVIDADE PRINCIPAL DA EMPRESA... 39
3.03 NÚMERO DE FUNCIONÁRIOS... 40
3.04 ATIVIDADE PRINCIPAL x NÚMERO DE FUNCIONÁRIOS... 40
3.05 PERCENTUAL DE SUBCONTRATAÇÃO... 41
3.06 MOTIVOS DE SUBCONTRATAÇÃO... 42
3.07 HOMOLOGAÇÃO DE EMPRESAS PARA SUBCONTRATAÇÃO... 42
3.08 LOCAL DE DESENVOLVIMENTO DE PROJETOS SUBCONTRATADOS………... 43
3.09 TAMANHO DE PROJETO………... 43
3.10 AÇÕES SEGUIDAS EM PROJETOS SUBCONTRATADOS ... 44
3.11 CLASSIFICAÇÃO DOS MAIORES DESAFIOS NOS PROJETOS SUBCONTRATADOS………... 45
4.01 FAIXA DE PONTUAÇÃO POR GRUPO DE PERGUNTAS... 71
4.02 LISTA COM A PONTUAÇÃO DAS EMPRESAS CANDIDATAS À HOMOLOGAÇÃO………... 71
ÍNDICE DE TABELAS
4.03 RESULTADO DA PROVA DE CONCEITO... 72
4.04 RESULTADO FINAL DA HOMOLOGAÇÃO... 72
4.05 EMPRESAS POR ESPECIALIDADE... 73
4.06 EXEMPLOS DE ARTEFATOS EQUIVALENTES... 76
5.01 EXEMPLOS DE MÉTRICAS... 94
5.02 EXEMPLOS DE FERRAMENTAS... 99
5.03 REQUISITOS... 100
5.04 ANÁLISE E DESIGN... 101
5.05 IMPLEMENTAÇÃO... 101
5.06 TESTE... 102
5.07 IMPLANTAÇÃO... 103
5.08 GERENCIAMENTO DE CONFIGURAÇÃO E MUDANÇA... 104
5.09 GERENCIAMENTO DE PROJETO... 104
5.10 AMBIENTE... 105
5.11 ARTEFATOS COMPLEMENTARES PARA SUBCONTRATAÇÃO... 106
5.12 PRINCIPAIS PAPÉIS NO GERENCIAMENTO DE SUBCONTRATAÇÃO... 108
CAPÍTULO 1
INTRODUÇÃO
A demanda de requisições para desenvolvimento de software associada ao curto prazo exigido para sua construção vem fazendo com que as empresas busquem alternativas que vão além de suas fronteiras de infra-estrutura tecnológica. Neste sentido, a prática da subcontratação está sendo a opção viável para resolver grande parte dos problemas encontrados pela área de tecnologias de informação e comunicação (TICs) das empresas.
Após pesquisa realizada para esta dissertação, os três principais motivadores que apareceram para justificar a subcontratação foram: com 62,50 %, as competências e tecnologias que não são de domínio da empresa; com 54,17, a redução de investimento fora do foco do negócio; e, com 50,00 %, a transformação de custo fixo em custo variável. Este resultado mostra motivos com percentuais bastante próximos, bem equilibrados, ratificando a orientação que a maioria das empresas que não tem como atividade fim o serviço de informática, está seguindo.
A subcontratação não se limita ao contrato. Ela exige parceria de intenções entre contratante e subcontratada para a busca do objetivo comum que é um produto de software dentro das especificações de prazo, custo e qualidade.
1.1 Objetivo
Este trabalho está direcionado para analisar a adoção de subcontratação parcial com empresas que desenvolvem software utilizando o processo iterativo. Dentro desta perspectiva, tem como objetivo a proposição de um modelo de gerenciamento de subcontratação que possa suportar este tipo de processo.
1.2 Metodologia
A metodologia empregada baseia-se na pesquisa bibliográfica sobre a parte teórica do Rational Unified Process (RUP), do Capability Maturity Model (CMM), do Project Management Body of Knowledge (PMBOK) e sobre os limites possíveis de intersecção entre o processo RUP e o PMBOK.
O trabalho empírico foi realizado a partir de um questionário distribuído no Brasil para as empresas que utilizam o processo RUP. Os dados coletados foram para analisar o nível de maturidade dessas empresas e para serem comparados a um modelo de subcontratação parcial, iterativo, cíclico e incremental que o processo RUP possibilita.
Ainda com relação a pesquisa de campo, foi feito um estudo de caso da Companhia Brasileira de Petróleo Ipiranga mostrando a evolução da Divisão de Informática antes e depois do RUP, quando ela passou a realizar subcontratação parcial de software com o processo iterativo.
1.3 Contribuição do trabalho
Quanto as contribuições do presente trabalho, os principais aspectos a ressaltar são:
• A primeira pesquisa sobre utilização de um processo iterativo de desenvolvimento de software realizada no Brasil;
• A prática de homologação de empresas desenvolvedoras de software, através de um processo de homologação;
• A construção de um modelo de gerenciamento de subcontratação de software; e,
• A possibilidade de subcontratação parcial de software, com desenvolvimento simultâneo e iterativo, através de um modelo de gerenciamento de subcontratação de software.
1.4 Organização da dissertação de tese
O texto compreende 6 capítulos que se desdobram em seções. Nesta introdução são formulados: o objetivo da pesquisa, a importância do tema e a metodologia empregada.
O segundo capítulo apresenta os aspectos conceituais sobre a teoria do processo iterativo, o modelo de maturidade e o gerenciamento de projeto de desenvolvimento de software. O capítulo três trata de uma pesquisa inédita sobre subcontratação e utilização do processo RUP. O quarto capítulo discute a subcontratação parcial com o processo RUP ou com as suas melhores práticas, traz a prática da homologação de empresas desenvolvedoras de software e a adoção da subcontratação através de alguns cenários propostos. O capítulo cinco aborda o gerenciamento de subcontratação. Ele condensa alguns conceitos de métrica e qualidade para embasar o modelo de gerenciamento de subcontratação de software que é proposto. Em seguida, é mostrada a experiência da Companhia Brasileira de Petróleo Ipiranga com a adoção do processo RUP e com a prática de subcontratação. Finalmente, nas conclusões do sexto capítulo são ressaltados os resultados obtidos pelo trabalho, feitas as considerações finais bem como são sugeridos tópicos para o prosseguimento da pesquisa.
Alguns dos termos técnicos empregados no texto, relativos a desenvolvimento de software e subcontratação, constam do glossário do Anexo I. As expressões definidas no Glossário encontram-se em negrito.
1. INTRODUÇÃO
2. ENQUADRAMENTO TEÓRICO
3. MAPEAMENTO DO RUP NAS EMPRESAS DO BRASIL
4. SUBCONTRATAÇÃO PARCIAL COM O RUP
5. GERENCIAMENTO DE SUBCONTRATAÇÃO
6. CONCLUSÃO
QUESTIONÁRIO GLOSSÁRIO
REFERÊNCIAS BIBLIOGRÁFICAS
Figura 1.01 - ESTRUTURA DA DISSERTAÇÃO DE TESE
CAPÍTULO 2
ENQUADRAMENTO TEÓRICO
A última década do século XX, principalmente em sua segunda metade, foi marcada por uma transformação que fez com que o emprego das tecnologias de informação e comunicação se tornasse um diferencial competitivo para modernização produtiva das empresas. Segundo CASTELLS (2000), embora o modo capitalista de produção seja caracterizado por sua expansão contínua, sempre tentando superar limites temporais e espaciais, foi apenas no final do século XX que a economia mundial conseguiu tornar-se verdadeiramente global com base na nova infra-estrutura, propiciada pelas tecnologias da informação e comunicação.
A aceleração e a confiabilidade das redes mudaram a maneira de trabalhar de uma parcela importante dos habitantes do planeta. O correio eletrônico e a Internet colocaram o computador como um nó de comunicação que é capaz de mexer com todo o universo profissional em todos os setores de atividade.
Essas modificações fizeram com que as empresas remodelassem seus processos para uma nova realidade. A área de informática deixou de ser monolítica e hermética e passou a desenvolver projetos com equipes multifuncionais, integrando profissionais de outros departamentos. As empresas não sustentaram mais os vultosos orçamentos de tecnologia de informação e comunicação. A dinâmica dos negócios passou a exigir prazos menores para os projetos. E também, a demora na manutenção dos sistemas, principalmente os que utilizam a Internet, passou a gerar prejuízos incalculáveis para a organização. Essas características fomentaram a terceirização e a subcontratação, estimularam a utilização de processos de engenharia de software e valorizaram o gerenciamento de projetos.
Neste capítulo são apresentados os fundamentos teóricos dos aspectos relevantes para o entendimento do gerenciamento de projetos com subcontratação parcial que é proposto no capítulo quatro.
O que se pretende é compilar o conhecimento essencial à compreensão do Rational
Model (CMM) e por último, sintetizar alguns conceitos sobre gerenciamento de projeto, principalmente os do Project Management Body of Knowledge (PMBOK).
2.1 RATIONAL UNIFIED PROCESS (RUP)
O fracasso da maioria dos projetos de desenvolvimento de software está associado a uma série de sintomas que vêm se repetindo na história e inspirando muitos pesquisadores a buscarem soluções para minimizar esse tipo de problema. JONES (1996) & YOURDON (1997), identificaram que a maioria dessas falhas está relacionada com:
• Conhecimento inadequado das necessidades dos stakeholders;
• Requisitos mal definidos e confusos;
• Módulos que não se integram;
• Dificuldade para manutenção e melhoria do software;
• Falhas do projeto identificadas tardiamente;
• Baixa qualidade do software;
• Baixo desempenho do software;
• Componentes da equipe trabalhando de formas diversas e gerando dificuldade para se reconstituir quem mudou o que, quando, onde e por que; e,
• Falta de confiança para liberação do software.
Assim como na medicina a febre é um sintoma e o seu tratamento não cura a doença, na engenharia de software não é diferente e cada sintoma identificado precisa ser inspecionado para associá-lo a uma ou mais causas que posteriormente deverão ser tratadas. KRUCHTEN (2000), descreve que as principais causas desses problemas estão ligadas a:
• Gerenciamento de requisitos realizado de forma inadequada;
• Comunicação ambígua e imprecisa;
• Arquitetura frágil;
• Complexidade exagerada;
• Inconsistências não detectadas (nas etapas de requisitos, design e implementação);
• Testes mal realizados;
• Avaliação subjetiva da situação do projeto;
• Falhas na avaliação e tratamento dos riscos;
• Mudanças realizadas de forma descontrolada; e,
• Automação insuficiente.
As premissas apresentadas sugerem que o tratamento dessas causas não só elimina os sintomas mas também melhora a qualidade do desenvolvimento e manutenção dos softwares, além de possibilitar um processo previsível.
Segundo KRUCHTEN (2000), os fatores causadores de problemas podem ser eliminados aplicando-se a combinação das melhores práticas utilizadas no RUP, conforme a seguir:
• Desenvolvimento iterativo;
• Gerenciamento de requisitos;
• Arquitetura componentizada;
• Modelagem visual (UML);
• Verificação contínua de qualidade; e,
• Gerenciamento de mudanças.
2.1.1 Melhores práticas
2.1.1.1 Desenvolvimento iterativo
A forma mais clássica das empresas desenvolverem projetos ainda é hoje, em sua maioria, através de processos que seguem uma organização seqüencial das disciplinas, passando por cada uma delas apenas uma vez. Nestas condições, conforme mostrado na figura 2.01, ao término da última disciplina tem-se um ciclo completo conhecido como ciclo de vida cascata.
Figura 2.01 – CICLO DE VIDA CASCATA
Fonte: RUP, Versão 2003
Observa-se na figura 2.02 que no desenvolvimento cascata o problema fundamental é dos riscos serem tratados tardiamente. Além disso, nesse modelo as métricas são pobres em previsibilidade, normalmente os testes e a integração geram atrasos e estouro no orçamento, não se consegue liberar os releases com rapidez e freqüentemente existe iteração não planejada.
Figura 2.02: RISCO NO CICLO DE VIDA CASCATA
Fonte: RUP, Versão 2003
Para evitar esses problemas, o RUP adota o conceito de iteração, conforme exemplo da figura 2.03. O desenvolvimento iterativo está associado com a idéia de percorrer várias vezes todas as disciplinas de desenvolvimento de tal forma que se possa ir refinando o entendimento do sistema e a cada vez, isto é, a cada iteração, possa acontecer a liberação de um produto executável, gradualmente mais completo.
Figura 2.03 – EXEMPLO DE CICLO DE VIDA ITERATIVO
Fonte: RUP, Versão 2003
O ciclo de vida de um projeto que utiliza o desenvolvimento iterativo, figura 2.04, consiste de uma ou mais iterações. Cada iteração possui um plano e resulta em uma versão do produto que passa por todas as atividades de desenvolvimento. Esta abordagem possibilita a intervenção dos envolvidos de modo que as inconsistências sejam detectadas com antecedência, lições possam ser obtidas no decorrer do projeto permitindo que o processo seja melhorado, e que a equipe de desenvolvimento possa focar nas questões mais críticas para o sucesso do projeto.
Figura 2.04 – CICLO DE VIDA ITERATIVO
Fonte: RUP, Versão 2003
Cada iteração resulta em um
release executável
• A abordagem iterativa facilita a redução dos riscos, uma vez que cada iteração agrega os elementos da iteração anterior. Assim, conforme figura 2.05, riscos que no modelo cascata só seriam descobertos durante a integração, no modelo iterativo costuma aparecer mais cedo;
• A abordagem iterativa permite que os requisitos não fiquem congelados, uma vez que poderão sofrer alterações durante o processo de desenvolvimento;
• A abordagem iterativa gera uma arquitetura mais sólida, pois os erros vão sendo corrigidos a cada iteração;
• O processo de desenvolvimento permite o aprendizado dos diversos papéis representados pelos integrantes da equipe durante o exercício de todo o ciclo de vida do projeto. O próprio processo pode ser melhorado e refinado com base no aprendizado do projeto;
• O ciclo de vida iterativo facilita a reutilização de software. As revisões de design nas iterações iniciais ajudam na identificação de reutilização tanto de códigos já construídos em outros projetos quanto de uma necessidade futura.
Figura 2.05 – COMPARAÇÃO DOS CICLOS DE VIDA CASCATA E ITERATIVO
Fonte: RUP, Versão 2003
2.1.1.2 Gerenciamento de requisitos
KRUCHTEN (2000) define requisito como uma condição ou uma capacidade com a qual o sistema deverá estar em conformidade.
O gerenciamento de requisitos no processo RUP é uma abordagem sistemática para localizar, documentar, organizar e controlar os requisitos variáveis de um sistema, estabelecendo e mantendo um acordo formal entre os stakeholders e a equipe de desenvolvimento, sobre os requisitos que eventualmente mudam ao longo do ciclo de vida do projeto.
Um bom gerenciamento de requisitos inclui: definição clara, identificação dos atributos necessários e rastreabilidade para outros requisitos e outros artefatos do projeto.
O RUP categoriza os requisitos conforme o modelo FURPS+ (GRADY, 1992), como é mostrado abaixo:
• Funcionalidade;
• Usabilidade;
• Confiabilidade;
• Desempenho;
• Suportabilidade.
O "+" em FURPS+ é para lembrar de incluir requisitos como:
• Restrições de design;
• Requisitos de implementação;
• Requisitos de interface;
• Requisitos físicos.
Conforme figura 2.06, os requisitos funcionais são organizados através de casos de uso.
Os casos de uso descrevem as funcionalidades do sistema percebidas pelos atores (FURLAN, 1998).
Figura 2.06 – EXEMPLO DE CASOS DE USO: CAIXA ELETRÔNICO
Fonte: RUP, Versão 2003
O RUP traz as seguintes definições:
Caso de uso - é uma seqüência de ações realizadas por um sistema, que gera um resultado observável de valor para um determinado ator;
Ator - é um agente fora do sistema que interage com o sistema.
Os casos de uso ajudam a colocar os requisitos em um contexto, contando uma história de como o sistema será utilizado.
O que torna o gerenciamento de requisitos mais complexo é a necessidade de mudanças.
Um requisito mudado traz impacto de tempo maior ou menor para implementação de uma nova característica mas também e principalmente, pode gerar impacto em outros requisitos.
2.1.1.3 Arquitetura componentizada
Conforme descrição do processo RUP, os componentes são grupos de código coesos, na forma de código fonte ou executável, com interfaces bem definidas e comportamentos que fornecem forte encapsulamento do conteúdo e são, portanto, substituíveis. As arquiteturas baseadas em componentes tendem a reduzir o tamanho efetivo e a complexidade da solução e, portanto, são mais robustas e flexíveis.
No paper de GARLAN & SHAW (1994) – An Introduction to Software Architeture – é sugerido um nível de design voltado para questões que vão: "além dos algoritmos e das estruturas de dados da computação. A projeção e a especificação da estrutura geral do sistema emergem como um novo tipo de problema. As questões estruturais incluem organização total e estrutura de controle global; protocolos de comunicação, sincronização e acesso a dados; atribuição de funcionalidade a elementos de design;
distribuição física; composição de elementos de design; escalonamento e desempenho; e seleção entre as alternativas de design."
No RUP, a arquitetura de um sistema de software (em um determinado ponto) é a organização ou a estrutura dos componentes significativos do sistema que interagem por meio de interfaces, com elementos constituídos de componentes e interfaces sucessivamente menores. Para solução de diferentes níveis de abstração é incentivado que os sistemas sejam estruturados em grupos de componentes que formem camadas umas sobre as outras de tal forma que as camadas superiores utilizem os serviços somente das camadas abaixo (nunca das camadas acima), conforme exemplo genérico da figura 2.07.
Figura 2.07 – ARQUITETURA EM CAMADAS
Fonte: RUP, Versão 2003
As primeiras iterações realizadas num projeto procuram minimizar os riscos de arquitetura, produzindo e validando um protótipo arquitetural executável dos casos de uso mais críticos, que gradualmente irá evoluindo até se tornar o sistema final em iterações posteriores. Procuram também diminuir os riscos relacionados a mudanças, desempenho, capacidade e confiabilidade, dentre outros, para que a capacidade funcional completa do sistema possa ser confiável para o seu prosseguimento e futura implantação.
O RUP suporta o desenvolvimento baseado em componentes das seguintes formas:
• A abordagem iterativa permite identificar componentes progressivamente e decidir quais desenvolver, quais reutilizar e quais comprar.
• O foco na arquitetura de software permite montar a estrutura, os componentes e como eles se integram, incluindo os padrões e os mecanismos fundamentais através dos quais eles interagem.
• Conceitos como pacotes, subsistemas e camadas são utilizados durante a disciplina Análise e Design para organizar componentes e especificar interfaces.
• Os testes são primeiramente organizados em componentes e, em seguida, em conjuntos maiores de componentes integrados.
2.1.1.4 Modelagem visual (UML)
KRUCHTEN (2000) define modelo como uma simplificação da realidade que descreve completamente um sistema sob uma perspectiva particular.
O Rational Unified Process define a Unified Modeling Language (UML), como o uso de notações de design gráficas e textuais, semanticamente ricas, para capturar designs de software.
Para FURLAN (1998), a UML é uma linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema e que pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação.
A UML vai além de uma simples padronização unificada, podendo ser usada no RUP para:
• Ajudar na compreensão de sistemas complexos;
• Explorar e comparar alternativas de design a um baixo custo;
• Formar uma base para implementação;
• Capturar requisitos com precisão;
• Comunicar decisões sem ambigüidade.
Segundo BOOCH (1995), serve ainda para:
• Comunicar decisões que não são óbvias ou que não podem ser deduzidas do próprio código;
• Fornecer semântica rica o suficiente para capturar todas as decisões estratégicas e táticas importantes;
• Oferecer uma forma concreta o suficiente para que as pessoas raciocinem e para que as ferramentas sejam manipuladas.
2.1.1.5 Verificação contínua de qualidade
Para o RUP, qualidade é algo pelo qual nos esforçamos para obter nos produtos,
produto que atende ou excede os requisitos acordados, avaliado por medidas e critérios preestabelecidos, e que é criado em um processo de comum acordo.
Definir o que é um software de qualidade é algo bastante complexo devido as diversas possibilidades de observação, segundo cada um dos envolvidos. Como saber quando o produto é bom o suficiente? Se o produto ainda não for bom o suficiente, como garantir que os envolvidos saibam disso?
A qualidade do software deve então estar previamente relacionada com os objetivos que o produto deverá atingir, de acordo com as expectativas dos envolvidos, e de forma que se possa estabelecer medidas para que essas expectativas sejam acompanhadas e alcançadas.
A figura 2.08, ilustra o custo da correção de um problema em relação ao tempo em que se demora para corrigi-lo. A localização e a solução dos problemas de software ficam de 100 a 1.000 vezes mais caros, se realizados após a implantação (KRUCHTEN, 2000). A verificação e o gerenciamento da qualidade durante o ciclo de vida do projeto são fundamentais para que seus objetivos possam ser atingidos dentro do planejado.
Figura 2.08 – CUSTO DE UM PROBLEMA EM RELAÇÃO AO TEMPO PARA CORRIGI-LO
Fonte: RUP, versão 2003
2.1.1.6 Gerenciamento de mudanças
Estabelecer um processo para controlar mudanças de forma documentada é a maneira de se obter maior consistência e segurança na condução do projeto. A documentação torna-se um local de consulta para que os envolvidos possam obter informações sobre o produto, as mudanças nele realizadas e o impacto que as mudanças geraram.
O gerenciamento de mudanças proposto no RUP, permite o controle de vários desenvolvedores, organizados em diferentes equipes, trabalhando em diferentes locais geográficos, para um mesmo projeto, com várias iterações e releases, e em diferentes plataformas.
O gerenciamento de mudanças através do RUP permite ainda que:
• O fluxo de trabalho da mudança de requisitos possa ser definido e repetido;
• As solicitações de mudança facilitem a comunicação de forma clara;
• Os espaços de trabalho isolados reduzam a interferência entre membros da equipe que trabalham em paralelo;
• Se possa obter métricas satisfatórias para avaliar objetivamente o status do projeto;
• Os depositórios de trabalho contenham todos os artefatos, facilitando consistência;
• A propagação da mudança possa ser avaliada e controlada; e,
• As mudanças possam ser mantidas em um sistema robusto e personalizável.
2.1.2 Estrutura do processo
O Rational Unified Process (RUP) é um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Tem como meta a garantia da produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis.
Como mostrado na figura 2.09, o processo RUP tem duas dimensões:
• O eixo vertical representando as disciplinas que agrupam as atividades a serem realizadas. Esse eixo está associado ao aspecto estático do processo, como ele é
descrito em termos de componentes do processo, atividades, fluxos de trabalho, artefatos e papéis;
• O eixo horizontal representando o tempo e mostrando os aspectos do ciclo de vida do processo à medida que se desenvolve. Está associado ao aspecto dinâmico do processo quando ele é aprovado, e é expresso em termos de fases, iterações e marcos.
Ainda na figura 2.09, o gráfico – que recebeu a alcunha de gráfico das baleias - mostra a concentração de trabalho, por disciplina, de acordo com a evolução das iterações.
Percebe-se, por exemplo, que nas iterações iniciais dedica-se mais tempo a disciplina de requisitos.
Figura 2.09 – ARQUITETURA GERAL DO RUP
Fonte: RUP, versão 2003
2.1.2.1 Estrutura estática
Esta estrutura mostra quem está fazendo o que, como e quando, através dos quatro elementos utilizados no processo RUP, conforme a seguir:
• Papel – quem;
• Artefato – o que;
• Atividade – como; e,
• Fluxo de trabalho – quando.
O RUP define cada um destes elementos da seguinte maneira:
• Papel - é um mecanismo de agrupamento que define um conjunto de responsabilidades em termos das atividades que esse papel pode realizar. Um papel pode ser desempenhado por uma pessoa ou por um conjunto de pessoas que trabalham juntas em equipe. Uma pessoa também pode desempenhar diversos papéis. Há momentos em que um papel pode estar diretamente relacionado a um cargo, mas isso não é obrigatório. O revisor de requisitos, o analista de testes, o arquiteto de software e o gerente de projeto são alguns exemplos de papéis;
• Artefatos - são as elaborações e os documentos de modelagem que as atividades desenvolvem, mantêm e usam como fonte de informações. Um artefato pode ser um documento, como documento de arquitetura de software, um modelo, como modelo de casos de uso, ou ainda, um elemento de modelo, como uma classe;
• Atividade - é uma unidade de trabalho que um papel pode ser solicitado a executar;
• Fluxo de trabalho- figura 2.10, é uma seqüência das atividades que produzem um resultado de valor observável.
Figura 2.10 – EXEMPLO DE DIAGRAMA DE ATIVIDADES DA DISCIPLINA DE REQUISITOS
Fonte: RUP, versão 2003
Uma das grandes dificuldades para descrever um processo é que existem muitas formas de organizar o conjunto de atividades em fluxos de trabalho. KRUCHTEN (2000) descreve a organização do RUP da seguinte maneira:
• Principais fluxos de trabalho
São nove fluxos de trabalho principais e eles representam a divisão de todos os papéis e atividades, dentro de grupamentos lógicos conhecidos como áreas de concentração ou disciplinas. Estão particionados em seis fluxos de engenharia e três fluxos de apoio. Os de engenharia são: modelagem de negócios, requisitos, analise e design, implementação, teste e implantação. E os de apoio:
gerenciamento de projeto, gerenciamento de configuração e mudança, e ambiente.
• Detalhamentos dos fluxos de trabalho
Cada um dos nove fluxos de trabalho principais endereça uma série de outros fluxos para facilitar o detalhamento dos diversos grupos de atividades que estejam as eles relacionadas. Esses diagramas mostram os papéis envolvidos, os artefatos de entrada e de saída e as atividades executadas.
• Planos de iteração
É uma forma de apresentar o processo onde se descreve a seqüência das atividades, suas dependências e os recursos a elas atribuídos para realização da iteração. A última atividade de cada iteração é a avaliação, onde os resultados são analisados com base nos critérios que foram previamente estabelecidos.
2.1.2.2 Estrutura dinâmica
Esta estrutura descreve desenvolvimento do ciclo de vida do processo RUP, baseado em fases, marcos e iterações.
O ciclo de vida é dividido em quatro fases seqüenciais: iniciação, elaboração, construção e transição. Como mostra a figura 2.11, a conclusão de cada fase é identificada por um marco principal e em cada final de fase é feita uma avaliação para se verificar se os objetivos foram alcançados.
Figura 2.11 - AS FASES E OS MARCOS DE UM PROJETO
Fonte: RUP, Versão 2003
Ao final das quatro fases, conclui-se um ciclo de desenvolvimento e se produz uma geração de software. Os ciclos subseqüentes são denominados de ciclos de evolução e acontecem a partir de melhorias sugeridas pelos usuários, mudanças de contexto, de tecnologia, etc. À medida que se atravessa um novo ciclo, uma nova geração de software é produzida.
Cada fase pode ser resumida da seguinte forma:
Iniciação
A fase de iniciação tem como meta principal estabelecer os objetivos do ciclo de vida do projeto a partir do consenso de todos os envolvidos. Nesta fase, procura-se também:
• Delimitar o escopo do projeto e os critérios de aceitação;
• Identificar os riscos do projeto;
• Identificar e detalhar os casos de uso críticos para arquitetura e para os negócios;
• Definir uma arquitetura candidata e demonstrá-la minimamente, se necessário;
• Estimar os custos;
• Preparar o ambiente de suporte para o projeto.
Elaboração
A fase de elaboração tem como meta principal criar uma base estável para a fase de construção. Esta fase prioriza os casos de uso que oferecem riscos de arquitetura e que já foram mapeados na fase de iniciação. O que se busca nesta fase é principalmente:
• Buscar a estabilidade da arquitetura e a redução dos riscos;
• Produzir um protótipo evolutivo dos componentes e um ou mais protótipos para diminuir os riscos e que são posteriormente descartados;
• Justificar a arquitetura, demonstrando que ela suportará os requisitos do projeto.
Construção
A fase de construção tem como meta principal detalhar o restante dos casos de uso e concluir o desenvolvimento do sistema com base na arquitetura definida. Os principais objetivos desta fase são:
• Diminuir os custos de desenvolvimento através da otimização de recursos;
• Buscar produtividade com qualidade e eficiência;
• Concluir a análise, o design, o desenvolvimento e o teste de todas as funcionalidades pendentes;
• Atingir o desenvolvimento de um produto completo de maneira iterativa e incremental;
• Buscar paralelismo entre o trabalho das equipes de desenvolvimento.
Transição
A fase de transição tem como meta principal assegurar que o software esteja disponível para seus usuários finais. Seus objetivos principais são:
• Validar o novo sistema em confronto com as expectativas dos envolvidos;
• Realizar operação paralela caso exista um sistema para ser substituído;
• Promover a conversão de bancos de dados operacionais;
• Treinar usuários e equipe de manutenção;
• Corrigir erros e realizar ajustes;
• Obter aceitação do produto pelo usuário;
• Implantar o sistema.
2.1.3 Áreas de concentração
KRUCHTEN (2003) define disciplina como uma coleção de atividades relacionadas que estão ligadas a maior área de interesse dentro do processo em geral.
Como já foi visto, o RUP é composto por nove disciplinas, sendo seis voltadas para a engenharia e três para apoiar o desenvolvimento do projeto. No entanto, conforme se pôde verificar, o processo RUP não traz nenhuma área de concentração dedicada a questão da subcontratação. O objetivo de cada disciplina pode ser resumido da seguinte forma:
Modelagem de negócios
• Entender a estrutura e a dinâmica da organização na qual o sistema será entregue;
• Identificar problemas correntes na organização e possíveis aperfeiçoamentos;
• Assegurar que o cliente, o usuário final e os desenvolvedores possuam a mesma compreensão da empresa; e,
• Produzir os requisitos de sistemas necessários para suportar os objetivos da organização.
Requisitos
• Estabelecer e manter com os envolvidos o entendimento sobre o que o sistema deve fazer;
• Permitir uma melhor compreensão dos requisitos aos desenvolvedores de sistemas;
• Definir os limites do sistema;
• Fornecer as bases para o planejamento das iterações;
• Fornecer as bases para estimativa de custo e tempo de desenvolvimento; e,
• Definir as interfaces do sistema baseado nas necessidades e objetivos dos usuários.
Análise e Design
• Transformar os requisitos dentro de um design do que será o sistema;
• Desenvolver uma arquitetura robusta para o sistema; e,
• Adaptar o design para combinar com o ambiente de implementação, projetando- o para fins de desempenho.
Implementação
• Preparar a organização do código em termos de implementação de subsistemas, organizados em camadas;
• Implementar classes e objetos em termos de componentes (código fonte, binários, executáveis, etc);
• Testar os componentes desenvolvidos como unidades; e,
• Integrar os resultados obtidos por implementadores individuais (ou equipes) em um sistema executável.
Teste
• Verificar a interação entre os objetos;
• Verificar a integração de todos os componentes de software;
• Verificar se todos os requisitos foram implementados corretamente, identificando os possíveis defeitos; e,
• Assegurar que os defeitos identificados foram tratados antes da entrega do software.
Implantação
• Descrever as atividades associadas a verificação de que o software esteja disponível ao usuário final.
Gerenciamento de Mudança e Configuração
• Identificar itens de configuração;
• Restringir alterações;
• Auditar alterações; e,
• Definir e gerenciar as alterações desses itens.
Ambiente
• Focar as atividades necessárias para configurar o processo para o projeto; e,
• Descrever as atividades requeridas para desenvolver as guias mestres ao suporte do projeto e fornecer, para a organização de desenvolvimento de software, o ambiente de processos e ferramentas que serão utilizados pela equipe de desenvolvimento.
Gerenciamento de Projeto
A disciplina de apoio gerenciamento de projeto teve sua abordagem influenciada pelo Project Management Body of Knowledge (PMBOK). Esta disciplina fornece uma estrutura por meio da qual um projeto pode ser criado e gerenciado de tal forma que tanto as seis disciplinas de engenharia quanto as outras duas disciplinas de apoio possam estar referenciadas e controladas.
• Fornecer uma estrutura capaz de gerenciar o projeto;
• Orientar o planejamento, a montagem da equipe, a execução e a monitoração do projeto; e,
• Fornecer uma estrutura para gerenciamento de riscos.
Não são cobertos aspectos referentes a:
• Gerenciar pessoal;
• Gerenciar orçamento; e,
• Gerenciar contratos.
A disciplina está mais voltada para os aspectos técnicos relacionados ao desenvolvimento iterativo e se destina principalmente a:
• Gerenciar riscos;
• Planejar o projeto de forma iterativa;
• Incentivar a utilização de métricas; e,
• Monitorar o progresso do projeto .
Independente dos aspectos não tratados nessa disciplina, o processo RUP oferece nela e em todas as outras, um recurso fundamental para ser utilizado na subcontratação de projetos que é o protocolo de comunicação através de artefatos com templates padronizados. Este recurso será melhor explorado no capítulo quatro.
2.2 CAPABILITY MATURITY MODEL (CMM)
A maturidade de um processo não é alcançada de forma revolucionária, mas sim em pequenas etapas evolutivas onde sua melhoria contínua é obtida através de fundamentos direcionados para este fim.
O Capability Maturity Model (CMM), fornece uma estrutura com cinco níveis de maturidade, figura 2.12, que seguem uma escala evolutiva, ordenada de um a cinco, e que permite medir a maturidade de um processo de software da organização, avaliar esse processo e priorizar os esforços para obtenção de sua melhoria.
Para o CMM, nível de maturidade é um estágio evolutivo bem definido em busca de um processo de software maduro.
Figura 2.12 – OS CINCO NÍVEIS DE MATURIDADE DO CMM
Fonte: Adaptado de CMU/SEI-93-TR-24
Cada nível de maturidade está dividido em áreas-chave do processo (KPA) que estabelece grandes temas a serem abordados, somando, no total dezoito áreas-chave.
Cada área-chave é detalhada nas práticas-chave que são os quesitos a serem cumpridos na implantação do modelo. As práticas-chave especificam o que deve ser cumprido exigindo documento, treinamentos ou políticas definidas para as atividades, mas nunca especificam como essas devem ser implementadas.
2.2.1 Níveis de maturidade
2.2.1.1 Nível 1 - Inicial
O nível 1 não descaracteriza a possibilidade de uma empresa nele enquadrada, poder desenvolver produtos de software de alta qualidade. Ocorre, no entanto, que esse desempenho está diretamente ligado a competência individual de cada um dos componentes da equipe envolvida. A mudança de pessoas poderá fazer a qualidade cair.
5 - Otimizado
3 - Definido
4 - Gerenciado
1 - Inicial
2 - Repetível
Processo disciplinado
Processo padronizado e consistente
Processo previsível
Processo continuamente melhorado
Para este nível não existe nenhuma área-chave associada e os maiores problemas são de ordem gerencial e não técnica, conforme exemplos a seguir:
• Processo é informal e imprevisível;
• Desempenho está na competência pessoal;
• Ausência de instrumentos gerenciais mínimos;
• Não há uniformidade e previsibilidade no andamento das tarefas;
• Alto esforço de manutenção; e,
• Processo de desenvolvimento é desorganizado e até caótico. Poucos processos são definidos e o sucesso depende de esforços individuais e heróicos.
2.2.1.2 Nível 2 - Repetível
No nível 2 os métodos de gerenciamento de software são documentados e acompanhados. Políticas organizacionais orientam os projetos estabelecendo processo de gerenciamento. Práticas bem sucedidas podem ser repetidas em novos projetos.
Custos e prazos são estabelecidos e cumpridos baseados em projetos similares que já foram desenvolvidos anteriormente. No nível 2 existem seis áreas-chave:
• Gerenciamento de requisitos;
• Planejamento de projeto de software;
• Acompanhamento e supervisão de projeto de software;
• Gerenciamento de subcontratação de software;
• Garantia da qualidade de software; e,
• Gerenciamento da configuração de software.
2.2.1.3 Nível 3 - Definido
No nível 3 a empresa possui um processo de desenvolvimento de software definido, padronizado e que é customizado para cada tipo de projeto. Este nível possui sete áreas-chave:
• Foco no processo da organização;
• Definição do processo da organização;
• Programa de treinamento;
• Gerenciamento integrado de software;
• Engenharia de produto de software;
• Coordenação intergrupos; e,
• Revisão por pares.
2.2.1.4 Nível 4 - Gerenciado
No nível 4 a empresa estabelece metas quantitativas de qualidade para os produtos e processos de software. É possível prever o desempenho dentro dos limites especificados e a gerência tem bases objetivas para tomada de decisão com subsídios para atuar no próprio processo. São duas áreas-chave no nível 4:
• Gerenciamento quantitativo do processo; e,
• Gerenciamento da qualidade do software.
2.2.1.5 Nível 5 - Otimizado
No nível 5 a empresa toda está voltada para a melhoria contínua do processo. As mudanças de tecnologia bem como as mudanças do próprio processo são gerenciadas de tal forma a não causarem impacto no produto final. Os processos de software são revistos para prevenir tipos de falhas já conhecidos e que normalmente se repetem. As lições aprendidas são disseminadas para outros projetos. As áreas-chave do nível 5 são:
• Prevenção de defeitos;
• Gerenciamento de mudança de tecnologia; e,
• Gerenciamento de mudança no processo.
2.2.2 Limitações do RUP
Quando se confronta as áreas-chave do CMM nível 2 com as disciplinas do RUP, figura 2.13, verifica-se que a área-chave gerenciamento de subcontratação de software não tem associação. Embora o RUP contribua para várias áreas-chave de todos os níveis do CMM, ainda assim, as empresas que o utilizam não estão totalmente cobertas para se candidatar ao CMM nível 2.
TABELA 2.01 – RELACIONAMENTO DO CMM NÍVEL 2 COM O RUP
RELACIONAMENTO ENTRE O CMM NÍVEL 2 E O RUP
Áreas-chave do CMM nível 2 Disciplinas do RUP - Gerenciamento de requisitos - Requisitos
- Planejamento de projeto de software - Gerenciamento de projeto - Acompanhamento e supervisão de
projeto de software
- Gerenciamento de projeto - Gerenciamento de subcontratação de
software
- Não tem
- Garantia da qualidade de software - Gerenciamento de projeto - Teste
- Gerenciamento da configuração de software
- Gerenciamento de configuração e mudanças
2.3 PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK)
O Project Management Body of Knowledge (PMBOK) é um guia de conhecimento das melhores práticas em gerenciamento de projetos que tem os seguintes objetivos principais:
• Reunir conhecimento já comprovado internacionalmente na área de gerenciamento de projetos, através de práticas tradicionais e práticas inovadoras e avançadas;
• Fornecer um guia genérico para todas as áreas de projeto, seja uma obra de construção civil, um processo de fabricação industrial ou ainda a produção de um software; e,
• Padronizar os termos utilizados no gerenciamento de projetos.
O PMBOK define o gerenciamento de projetos como a aplicação de conhecimentos, habilidades, ferramentas e técnicas em projetos com o objetivo de atingir ou até mesmo exceder às necessidades e expectativas dos clientes e demais partes interessadas no projeto.
Um projeto é um tipo de empreendimento com características próprias, tendo princípio e fim formalmente estabelecidos, e que é conduzido por pessoas com o objetivo de atingir metas estabelecidas dentro de parâmetros de prazo, custo e qualidade.
Um projeto envolve decisões típicas relacionadas a:
• Escopo, prazo, custo e qualidade;
• Diferentes necessidades e expectativas dos clientes e partes interessadas;
• Identificação de requisitos.
O gerenciamento de projetos é um esforço interativo que faz com que alterações em uma área possam vir a influenciar outras. Para auxiliar nesse entendimento dessa integração e do relacionamento entre as áreas, o PMBOK propõe que o gerenciamento de projetos seja organizado em termos de processos e das interações entre eles.
Os projetos são compostos por processos. O PMBOK define processo como uma série de ações que geram resultados.
Normalmente os processos se enquadram nas seguintes categorias:
• Processos do gerenciamento de projetos – Descrição, organização e conclusão do trabalho do projeto;
• Processos orientados ao produto – Especificação e criação dos produtos do projeto.
É importante observar que existe uma interação e uma sobreposição entre os processos do gerenciamento de projetos e os processos orientados ao produto durante todo o projeto. Pode-se exemplificar o PMBOK na primeira categoria e o RUP na segunda.
2.3.1 Processos do gerenciamento de projetos
2.3.2 Grupos de processos
O PMBOK organiza os processos de gerenciamento de projetos em cinco grupos, conforme a seguir:
• Processos de iniciação – Reconhecer que um projeto ou fase deve começar e se comprometer com a sua execução;
• Processos de planejamento – Planejar e manter um esquema de trabalho viável para atingir aqueles objetivos de negócio que determinaram a existência do projeto;
• Processos de execução – Coordenar pessoas e outros recursos para realizar o planejamento;
• Processos de controle – Assegurar que os objetivos do projeto estão sendo atingidos, através da monitoração e da avaliação do seu progresso, tomando ações corretivas quando necessárias; e,
• Processos de encerramento – Formalizar a aceitação do projeto ou fase e fazer o seu encerramento de forma organizada.
Figura 2.13 – RELACIONAMENTO ENTRE OS GRUPOS DE PROCESSO EM CADA FASE
Fonte: PMBOK, Versão 2000
Os processos do grupo de processos são interligados através de entradas e saídas, da seguinte forma:
• Entradas – Documentos ou itens documentáveis que influenciarão o processo;
Processos de Iniciação
Processos de Encerramento
Processos de Execução Processos de
Controle
Processos de Planejamento
As setas representam os fluxos de informação.
• Ferramentas e técnicas – Mecanismos aplicados às entradas para criar as saídas;
e,
• Saídas – Documentos ou itens documentáveis resultantes do processo.
2.3.3 Áreas de conhecimento
As áreas de conhecimento do gerenciamento de projetos descrevem os conhecimentos e práticas em gerenciamento de projetos em termos de processos que as compõem, levando em consideração o seguinte:
• Cada área de conhecimento se refere a um aspecto a ser considerado dentro do gerenciamento de projetos; e,
• A não execução dos processos de uma área afeta negativamente o projeto, pois o projeto é um esforço integrado.
Os processos estão organizados em nove áreas de conhecimento, cada uma com os objetivos a seguir:
• Integração – O gerenciamento da integração do projeto descreve os processos necessários para assegurar que os diversos elementos do projeto sejam adequadamente coordenados;
• Escopo – Descreve os processos necessários para assegurar que o projeto contemple todo o trabalho requerido para contemplar o projeto com sucesso;
• Tempo – Processos necessários para assegurar que o projeto termine dentro do prazo previsto;
• Custo – Processos necessários para assegurar que o projeto termine dentro do orçamento aprovado;
• Qualidade – Processos necessários para assegurar que as necessidades que originaram o desenvolvimento do projeto sejam atendidas;
• Recursos Humanos – Processos necessários pra proporcionar a melhor utilização das pessoas envolvidas no projeto;
• Comunicação – Processos necessários para assegurar que a geração, captura, distribuição, armazenamento e apresentação das informações do projeto sejam feitas de forma adequada e no tempo certo;
• Risco – Processos necessários para a identificação, análise e resposta a riscos do
• Aquisição – Processos necessários para a aquisição de mercadorias e serviços fora da organização que desenvolve o projeto.
2.3.4 Mapeamento dos processos de gerenciamento de projetos
Conforme figura 2.15, criando-se o relacionamento entre os grupos de processos e as áreas de conhecimento, pode-se visualizar de uma forma bastante resumida onde se encaixa cada um dos trinta e nove processos que compõe as nove áreas de conhecimento.
Tabela 2.02 – MAPEAMENTO DOS PROCESSOS DE GERENCIAMENTO DE PROJETO EM GRUPOS DE PROCESSOS E ÁREAS DE CONHECIMENTO
GRUPOS ÁREAS
Iniciação Planejamento Execução Controle Encerramento
4. Integração 4.1 Desenvolvimento do plano do projeto
4.2 Execução do plano do projeto
4.3 Controle integrado de mudanças 5. Escopo 5.1 Iniciação 5.2 Planejamento do
escopo
5.3 Detalhamento do escopo
5.4 Verificação do escopo 5.5 Controle de mudança do escopo
6. Tempo 6.1 Definição das
atividades
6.2 Sequenciamento das atividades
6.3 Estimativa da duração das atividades 6.4 Desenvolvimento do
cronograma
6.5 Controle de cronograma
7.Custo 7.1 Planejamento dos
recursos
7.2 Estimativa do custo 7.3 Orçamento do custo
7.4 Controle de custo
8. Qualidade 8.1 Planejamento da qualidade
8.2 Garantia da qualidade
8.3 Controle de qualidade 9. Recursos
Humanos
9.1 Planejamento organizacional 9.2 Montagem da equipe
9.3 Desenvolvimento da equipe
10. Comunicação 10.1 Planejamento das comunicações
10.2 Distribuição das informações
10.3 Relato de desempenho
10.4 Encerramento administrativo 11. Risco 11.1 Planejamento da
gerência de risco 11.2 Identificação dos
riscos
11.3 Análise qualitativa dos riscos
11.4 Análise quantitativa dos riscos
11.5 Planejamento de respostas a riscos
11.6 Controle e monitoração
12. Aquisição 12.1 Planejamento das aquisições 12.2 Preparação das
aquisições
12.3 Pedido de propostas 12.4 Seleção de
fornecedores 12.5 Administração
dos contratos
12.6 Encerramento dos contratos
Fonte: PMBOK, Versão 2000
2.3.5 Incompatibilidades e oportunidades com o RUP
O PMBOK e o RUP têm propostas diferentes. Enquanto o primeiro é direcionado através de processos de gerenciamento de projetos, em geral; o segundo, tem seus processos orientados ao produto de software. No entanto, apesar das diferenças e incompatibilidades estruturais, pode-se pensar na utilização de algumas áreas de conhecimento do PMBOK para preencher lacunas do RUP que uma empresa julgue necessárias para formalização de seus processos.
A vantagem de se pensar em processos de forma complementar ao RUP é que através do PMBOK pode-se criar processos híbridos utilizando as áreas de conhecimento e gerenciar todos os tipos de projeto da área de tecnologia da informação e comunicação (TICs), independente de ser ou não um projeto de desenvolvimento de software.
CAPÍTULO 3
MAPEAMENTO DO RUP NAS EMPRESAS DO BRASIL
O mapeamento aqui apresentado é o resultado da 1a Pesquisa Brasileira sobre a Utilização do RUP. Trata-se de uma pesquisa inédita que contou com a colaboração dos principais usuários do país, orientados a informar sobre o histórico do RUP em suas respectivas empresas e sobre o nível de maturidade em que se encontram.
Particularmente no que se refere a subcontratação, o RUP até a versão 2003.06 não apresentou nenhuma solução inserida no processo, deixando assim uma lacuna para seus usuários. Por esta razão, direcionou-se a pesquisa para buscar informações referentes a subcontratação para o desenvolvimento de software.
3.1 METODOLOGIA
O método de levantamento utilizado para a obtenção das respostas foi o questionário estruturado (ANEXO II), aplicado em amostra de usuários RUP e destinado a provocar informações específicas dos respondentes.
O questionário foi composto de perguntas fechadas, excetuando-se apenas a pergunta oito, que tratou do tamanho dos projetos e a pergunta cinqüenta e seis, que deixou a opção para comentários adicionais. As perguntas foram elaboradas de forma diversificada, cabendo aplicá-las de acordo com o propósito a ser obtido, conforme a seguir:
• Única – quando se buscava apenas uma resposta;
• Múltipla – quando se buscava opcionalmente a combinação de respostas;
• Ordenada – quando se buscava uma graduação decrescente das respostas;
• Escalar – quando se buscava o enquadramento em uma escala pré-determinada;
• Texto – quando se buscava resposta para uma pré-codificação difícil ou impossível.
