Apostila Gerencia de Projetos de Software

CURSO DE PS-GRADUAO LATO SENSU (ESPECIALIZAO) A DISTNCIA MELHORIA DE PROCESSO DE SOFTWARE LIVRE
Gerncia de Projetos de Software
Ana Cristina Rouiller
Universidade Federal de Lavras - UFLA
Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE Lavras MG
Parceria Universidade Federal de Lavras - UFLA Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE Reitor Antnio Nazareno Guimares Mendes Vice-Reitor Elias Tadeu Fialho Diretor da Editora Marco Antnio Rezende Alvarenga Pr-Reitor de Ps-Graduao Joel Augusto Muniz Pr-Reitor Adjunto de Ps-Graduao Lato Sensu Marcelo Silva de Oliveira Coordenao do curso Ana Cristina Rouiller Guilherme Bastos Alvarenga Marcelo Silva de Oliveira Presidente do Conselho Deliberativo da FAEPE Luiz Antnio Lima Editorao Centro de Editorao Quality Group Impresso Grfica Universitria/UFLA Ficha Catalogrfica Preparada pela Diviso de Processos Tcnicos da Biblioteca Central da UFLA Rouiller, Ana Cristina Gerncia de Projetos de Software/Ana Cristina Rouiller. Lavras: UFLA/FAEPE, 2008. 85 p.:il. (Curso de Ps-graduao Lato Sensu (Especializao) a Distncia Produo de Software (com nfase em Software Livre) Bibliografia 1. Sistema de informao. 2. Tecnologia de informao. 3. Gerenciamento de software. 4. Software. 5. Projeto. 6. Gerncia. I. Universidade Federal de Lavras. II. Fundao de Apoio ao Ensino, Pesquisa e Extenso. III. Ttulo. Nenhuma parte desta publicao pode ser reproduzida, por qualquer meio, sem a prvia autorizao da FAEPE.
SUMRIO
Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE....................................................................................2
Parceria..........................................................................................................145 Reitor ............................................................................................................145 Vice-Reitor.....................................................................................................145 Diretor da Editora...........................................................................................145 Pr-Reitor de Ps-Graduao.......................................................................145 Pr-Reitor Adjunto de Ps-Graduao Lato Sensu....................................145 Coordenao do curso..................................................................................145 Presidente do Conselho Deliberativo da FAEPE .........................................145 Editorao .....................................................................................................145 Impresso......................................................................................................145 Nenhuma parte desta publicao pode ser reproduzida, 145 Introduo 7 1.1 Projeto e a Gerncia de Projetos..........................................................................9 1.2 Motivao e Relevncia da Gerncia de Projetos..............................................10 1.3 As Dificuldades do Gerenciamento de Projetos de Software.............................11 1.4 Estrutura do Mdulo............................................................................................12 Modelos, Padres e Normas e a Gerncia de PRojetos 14 2.1 Processos de Gerenciamento da ISO/IEC15504................................................14 2.2 PMBOK................................................................................................................18 2.2.1 Gerncia de integrao de projetos........................................................19 2.2.2 Gerncia de escopo de projetos..............................................................20 2.2.3 Gerncia de tempo de projetos...............................................................21 2.2.4 Gerncia de custo de projetos.................................................................21 2.2.5 Gerncia da qualidade de projetos.........................................................22 2.2.6 Gerncia de recursos humanos de projetos...........................................22 2.2.7 Gerncia de comunicao de projetos....................................................22 2.2.8 Gerncia de risco de projetos..................................................................23 2.2.9 Gerncia de aquisio de projetos..........................................................23 2.3 Modelagem do Sistema de Processos dE Empresa de Software......................24 2.4 Elementos essenciais para criar um processo de gerncia de projetos.............25 2.5 Consideraes.....................................................................................................27 Poltica Organizacional e Padres ADotados para A definio do ProGer 30 3.1 pOLTICA oRGANIZACIONAL Considerada para o ProGer..............................30 3.1.1 Caracterizao da empresa....................................................................30 3.1.2 Metas pretendidas com a gerncia de projetos......................................32 3.2 Modelos, NOrmas e Padres Utilizados para a Definiao do ProGer................32 ProGER: Processo de Gerncia de Projetos de Software 36 4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................36 4.1.1 Controle e avaliao................................................................................39
4.2 Stakeholders .......................................................................................................41 4.3 Artefatos .............................................................................................................42 4.3.1 Documento de requisitos.........................................................................44 4.3.2 Proposta tcnica......................................................................................48 4.3.3 Proposta Comercial ................................................................................50 4.3.4 Plano de Projeto......................................................................................52 4.3.5 Relatrio de teste.....................................................................................55 Nome 55 Assinatura 55 4.3.6 Ata de reunio.........................................................................................55 4.3.7 Relatrio de visitas tcnicas....................................................................56 RELATRIO VISITA TCNICA.......................................................................58 Solicitante: 58 Data Solicitao: 58 Local: 58 Data Entrega Servio: 58
Problema / Requisio...............................................................................................................................................58
Nome 58 Assinatura 58 4.3.8 Relatrio de aceite...................................................................................58 4.3.9 Ordem de Servio....................................................................................60 ORDEM DE SERVIO....................................................................................60 Solicitante: 60 Data Solicitao: 60 Local: 60 Data Entrega Servio: 60 Nome 60 Assinatura 60 4.4 Fluxos de Trabalho .............................................................................................60 4.4.1 Fluxo de captao de projetos................................................................61 4.4.2 Fluxo de execuo de projetos ...............................................................65 4.4.3 Fluxo de avaliao de projetos................................................................69 4.5 Consideraes ....................................................................................................71 Ferramentas para APOIO Automatizado ao ProGer 65 5.1 Ferramentas Utilizadas em Conjunto com o ProGer..........................................67 5.1.1 Microsoft Word ........................................................................................67 5.1.2 Microsoft Project .....................................................................................67 5.1.3 Microsoft excel.........................................................................................68 5.1.4 Mantis......................................................................................................68 5.1.5 FreeVCS..................................................................................................69 5.1.6 Microsoft outlook......................................................................................69 5.1.7 Microsoft Windows Live Messenger........................................................69 5.1.8 Base de acompanhamento de projetos...................................................70 CONCLUSO 77 REFERNCIAS BIBLIOGRFICAS 79 APNDICE A 86 APNDICE B 1
LISTA DE FIGURAS
FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto 8 FIGURA 2.1 As dimenses do modelo de referncia da ISO/IEC15504 15 FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19 FIGURA 2.3 reas do gerenciamento de projetos do PMBOK 20 FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de software 24 26 FIGURA 2.5 Modelo para criao de processo de gerenciamento de projetos de software 26 FIGURA 3.1 Porte das empresas, segundo a fora de trabalho efetiva 31 FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37 FIGURA 4.2 Ciclo PDCA de controle de processos 40 FIGURA 4.3 Organograma sugerido 42 FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43 TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos projetos 43 TABELA 4.2 Sugesto de padro para nomeao dos artefatos 43 FIGURA 4.5 Sugesto de contedo para um documento de requisitos 47 FIGURA 4.6 Sugesto de contedo para uma proposta tcnica 50 FIGURA 4.7 Contedo para uma proposta comercial 52 FIGURA 4.8 Sugesto de contedo para um plano de projeto 55 FIGURA 4.9 Modelo de relatrio de teste 55 FIGURA 4.10 Modelo de ata de reunio 56 FIGURA 4.11 Modelo de relatrio de visita tcnica 57 FIGURA 4.12 Modelo de relatrio de aceite 58 FIGURA 4.13 Modelo de uma ordem de servio 59 FIGURA 4.14 Primitivas do flowchart 60 FIGURA 4.15 Resumo do fluxo de captao de projetos 61 TABELA 4.3 Sugesto de categorizao de nveis de profissionais para uma empresa de pequeno porte 62 FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto 63 TABELA 4.4 Mtricas sugeridas para o fluxo de captao de projetos 63 FIGURA 4.17 Resumo do fluxo de execuo de projeto 65 FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto 66 TABELA 4.5 Mtricas sugeridas para o fluxo de execuo de projetos 67 FIGURA 4.19 Resumo do fluxo de execuo de projetos 68 TABELA 4.6 Mtricas sugeridas para o fluxo de avaliao de projetos 69 TABELA 4.7 Relao de alguns procedimentos do proger e as reas de conhecimento do PMBOK. 70 FIGURA 5.1 Viso do cadastramento de projetos 71 FIGURA 5.2 Viso do cadastramento de fases do projeto 71
FIGURA 5.3 73 FIGURA 5.4 74 FIGURA 5.5 74 FIGURA 5.6 FIGURA 5.7 75 FIGURA 5.8
Viso do cadastramento de macro-atividades Viso do apontamento de horas nas macro-atividades Viso de projetos por fase e cliente Viso das horas gastas nos projetos Uma viso das horas gastas por colaborador Viso diria do trabalho do executor
72 73 74 74 75 75
LISTA DE TABELAS
FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto 8 FIGURA 2.1 As dimenses do modelo de referncia da ISO/IEC15504 15 FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19 FIGURA 2.3 reas do gerenciamento de projetos do PMBOK 20 FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de software 24 26 FIGURA 2.5 Modelo para criao de processo de gerenciamento de projetos de software 26 FIGURA 3.1 Porte das empresas, segundo a fora de trabalho efetiva 31 FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37 FIGURA 4.2 Ciclo PDCA de controle de processos 40 FIGURA 4.3 Organograma sugerido 42 FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43 TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos projetos 43 TABELA 4.2 Sugesto de padro para nomeao dos artefatos 43 FIGURA 4.5 Sugesto de contedo para um documento de requisitos 47 FIGURA 4.6 Sugesto de contedo para uma proposta tcnica 50 FIGURA 4.7 Contedo para uma proposta comercial 52 FIGURA 4.8 Sugesto de contedo para um plano de projeto 55 FIGURA 4.9 Modelo de relatrio de teste 55 FIGURA 4.10 Modelo de ata de reunio 56 FIGURA 4.11 Modelo de relatrio de visita tcnica 57 FIGURA 4.12 Modelo de relatrio de aceite 58 FIGURA 4.13 Modelo de uma ordem de servio 59 FIGURA 4.14 Primitivas do flowchart 60 FIGURA 4.15 Resumo do fluxo de captao de projetos 61 TABELA 4.3 Sugesto de categorizao de nveis de profissionais para uma empresa de pequeno porte 62 FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto 63 TABELA 4.4 Mtricas sugeridas para o fluxo de captao de projetos 63 FIGURA 4.17 Resumo do fluxo de execuo de projeto 65 FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto 66 TABELA 4.5 Mtricas sugeridas para o fluxo de execuo de projetos 67 FIGURA 4.19 Resumo do fluxo de execuo de projetos 68 TABELA 4.6 Mtricas sugeridas para o fluxo de avaliao de projetos 69 TABELA 4.7 Relao de alguns procedimentos do proger e as reas de conhecimento do PMBOK. 70 FIGURA 5.1 Viso do cadastramento de projetos 71 FIGURA 5.2 Viso do cadastramento de fases do projeto 71 FIGURA 5.3 Viso do cadastramento de macro-atividades 72
EDITORA UFLA / FAEPE Gerncia de Projetos de Software
73 FIGURA 5.4 74 FIGURA 5.5 74 FIGURA 5.6 FIGURA 5.7 75 FIGURA 5.8
Viso do apontamento de horas nas macro-atividades Viso de projetos por fase e cliente Viso das horas gastas nos projetos Uma viso das horas gastas por colaborador Viso diria do trabalho do executor
73 74 74 75 75
1
INTRODUO
A Engenharia de Software tem por finalidade auxiliar na construo de software da melhor maneira possvel [Pressman1995]. Desde os anos 1960, quando a frase the software crisis foi pronunciada, muitos problemas desta rea foram identificados, e muitos deles ainda persistem, tais como [Gibbs1994]: Previso pobre desenvolvedores no prevem adequadamente quanto tempo e esforo sero necessrios para produzir um sistema de software que satisfaa s necessidades (requisitos) dos clientes/usurios. Sistemas de software so geralmente entregues muito tempo depois do que fora planejado; Programas de baixa qualidade programas de software no executam o que o cliente deseja, conseqncia, talvez, da pressa para se entregar o produto. Os requisitos originais podem no ter sido, completamente, especificados ou podem apresentar contradies e isto pode ser descoberto muito tarde durante o processo de desenvolvimento; Alto custo para manuteno a manuteno pode ser corretiva, quando ocorrem enganos (erros, falhas) no sistema j entregue, ou evolutiva quando novas caractersticas so adicionadas ao sistema de software. Ambas so caras quando o sistema original foi construdo sem uma arquitetura clara e visvel; Duplicao de esforos difcil compartilhar solues ou reusar cdigos, em funo das caractersticas de algumas linguagens adotadas, por falta de confiana no cdigo feito por outra pessoa e at mesmo pela ausncia/deficincia de documentao das rotinas e dos procedimentos j construdos.
Para solucionar alguns destes problemas muitas empresas de software tm adotado metodologias de desenvolvimento de software. Todavia, os paradigmas metodolgicos para desenvolvimento de software tm sido considerados somente em termos de um mtodo de anlise/projeto/implementao, isto , um conjunto de conceitos, tcnicas e notaes. Esta viso elimina os aspectos tecnolgicos,
contextuais e organizacionais que potencialmente existem dentro de um processo de software. De forma geral, podemos dividir as funes de uma empresa de software em trs grupos principais [Garg1996]: definir, analisar, simular, medir e melhorar os processos da organizao; construir o produto de software; medir, controlar, modificar e gerenciar os projetos de software.
Estes trs grupos so abordados, respectivamente, pela engenharia do processo, pela engenharia do produto e pelo gerenciamento de projeto. O relacionamento entre estes grupos mostrado na Figura 1.1 [Garg1996]. A engenharia do produto encarregada do desenvolvimento e manuteno dos produtos e servios de software. A principal figura da engenharia do produto a metodologia de desenvolvimento, que engloba uma linguagem de representao, um modelo de ciclo de vida e um conjunto de tcnicas. Os ambientes tradicionais de desenvolvimento de software tm se preocupado essencialmente com a engenharia do produto, assumindo um processo implcito e tendo como foco o produto. Todavia, a engenharia do produto por si s insuficiente para suprir as necessidades de uma organizao que desenvolve software e torn-la mais produtiva e adequada s exigncias do mercado.
Experincias passadas Requisitos do processo Engenharia do processo Modelo do processo Gerenciamento de projeto Processo de desenvolvimento Engenharia do produto Produto de software Requisitos do projeto Requisitos do produto
FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto
Introduo
A engenharia de processo tem como metas a definio e a manuteno dos processos de uma organizao. Ela deve ser capaz de facilitar a definio, a anlise e a simulao de um processo, assim como estar apta a implant-lo, avali-lo, medilo e melhor-lo. A engenharia de processo pode ser vista como uma extenso da funo tradicional da garantia de qualidade e trata os processos de software de uma forma sistemtica, com um ciclo de vida bem definido. Contudo, a grande maioria das organizaes que desenvolvem software sente muita dificuldade em entender, definir e gerenciar estes processos. As empresas de software devem buscar os seus prprios ambientes para existirem e operarem. Abordagens da indstria manufatureira, por exemplo, no tm demonstrado serem adequadas indstria de software. O gerenciamento de projeto objetiva assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessrios para um projeto produzir um produto e/ou servio, de acordo com seus requisitos. Todavia, gerenciar projetos de software uma atividade complexa devido a uma srie de fatores, tais como: dinamicidade do processo, grande nmero de variveis envolvidas, exigncia de adaptabilidade ao ambiente de desenvolvimento e constantes alteraes no que foi planejado. Estes fatores dificultam o trabalho das equipes de desenvolvimento na medio do desempenho dos projetos, na verificao de pontos falhos, no registro de problemas, na realizao de estimativas e planejamentos adequados. Este mdulo se concentra nas reas de engenharia de processo e gerenciamento de projetos. 1.1 PROJETO E A GERNCIA DE PROJETOS
Um projeto pode ser definido como um empreendimento temporrio com o objetivo de criar um produto, servio ou resultado nico [PMBOK2000] A temporalidade de um projeto significa que um projeto deve possuir um inicio e um fim definido e estabelecido. O final pode ser quando os objetivos do projeto forem alcanados, ou quando ele cancelado (por se chegar a uma concluso de que os objetivos no podero ser alcanados ou pela mudana das necessidades). A meta da gerncia de projetos conseguir exceder as necessidades e expectativas dos stakeholders1[PMBOK2000]. Todavia, satisfazer ou exceder estas necessidades envolve um balanceamento entre as vrias demandas concorrentes em relao aos itens abaixo:
1
escopo, tempo, custo e qualidade (objetivos do projeto);
Stakeholders so os indivduos ou as organizaes que esto ativamente envolvidos em um projeto, cujos interesses podem afetar positivamente ou negativamente o resultado da execuo do projeto [PMBOK2000].
10
stakeholders com necessidades e expectativas diferenciadas; e requisitos identificados (necessidades) e requisitos no identificados (expectativas).
1.2
MOTIVAO E RELEVNCIA DA GERNCIA DE PROJETOS
Alguns estudos e pesquisas que foram realizados nos anos 1990 demonstraram que o gerenciamento de projeto a causa mais evidente das falhas na execuo e entrega de produtos e servios de software. O SEI-Software Engineering Institute constatou, j em 1993, que o principal problema que aflige as organizaes de software gerencial e preconizou que: as organizaes precisam vencer o seu buraco negro que o seu estilo de gerenciar de maneira informal, sem mtodos e sem tcnicas [Paulk1993]. Um estudo conduzido pelo DoD-Department of Defense [DOD1994] indicou que 75% de todos os sistemas de software falham e que a causa principal o pobre gerenciamento por parte do desenvolvedor e adquirente, deixando claro que o problema no de desempenho tcnico. O estudo realizado pelo Standish Group [Standish1995], chamado de relatrio do Chaos, focou a indstria de software comercial. Esse estudo identificou que: as empresas dos Estados Unidos gastaram $81 bilhes em projetos de software que foram cancelados em 1995; 31% dos projetos estudados foram cancelados antes de estarem concludos; 53% dos projetos de software que foram concludos excederam mais do que 50% a sua estimativa de custo; somente 9% dos projetos, em grandes organizaes, foram entregues no tempo e oramento previstos; para organizaes de pequeno e mdio porte os nmeros melhoraram em 28% e 16%, respectivamente. Este relatrio aponta o gerenciamento de software como sendo a razo para o sucesso ou a falha de um projeto de software. Atravs de uma anlise e acompanhamento de cem projetos de software, Jones [Jones1996] relata: os seis primeiros dos dezesseis fatores associados aos desastres do software so falhas especficas no domnio do gerenciamento de projeto, e os trs dos outros dez fatores restantes esto indiretamente associados s praticas de gerenciamento pobre. Walker [Walker1997] conclui que: o desenvolvimento de software ainda imprevisvel; somente 10% dos projetos de software so entregues com sucesso dentro das estimativas de oramento e custo; a disciplina de gerncia mais um discriminador de sucesso ou falha do que so os avanos tecnolgicos e a quantidade de softwares jogados fora, e que tem necessidade de re-trabalho, so um indicativo de processo imaturo.
Introduo
11
Muitas pesquisas enfatizam que o gerenciamento a principal causa do sucesso ou fracasso dos projetos de software. Apesar disso, o gerenciamento de projetos de software ainda pouco abordado e praticado nas empresas de software [Machado2001]. Jones [Jones1999] destaca que a ausncia de um processo de gerenciamento apropriado, aliado s estimativas deficientes de custo e de tempo, umas das principais causas das falhas dos projetos de software. Os principais padres e normas para SPA/SPI (Software Process Assessment/ Software Process Improvement)2 tm colocado o gerenciamento de projetos como um dos requisitos bsicos para que uma empresa inicie a melhoria de seu processo. Contudo, a introduo de padres e normas dentro das organizaes de software tem se mostrado complexo demais, alm de causar uma sobrecarga de trabalho significativa. Segundo Belloquin [Belloquin1999], estes padres e normas definem prticas que devem ser realizadas, porm no determinam como execut-las. Ns acreditamos que a existncia de procedimentos padronizados e de fcil compreenso pode ser de grande valor, fornecendo uma orientao aos gerentes de projeto e dificultando a ocorrncia de falhas graves de gerenciamento por falta de experincia. 1.3 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE
J em 1989, Humphrey [Humphrey1989] constatou que: a ausncia de prticas administrativas no desenvolvimento de software a principal causa de srios problemas enfrentados pelas organizaes, tais como: atrasos em cronogramas, custo maior do que o esperado e presena de defeitos, ocasionando uma srie de inconvenincias para os usurios e enorme perda de tempo e de recursos. Ainda hoje esta afirmao tem sido confirmada por diversos autores. Na atual cultura das organizaes de software o planejamento, quando ocorre, feito de forma superficial [Weber1999] [Sanches2001]. Muitos projetos de software so realizados sem um planejamento de como a idia modelada pelo levantamento de requisitos e necessidades dos clientes pode ser transformada em produto. Os gerentes de projeto de software esto desacostumados a estimar [Vigder1994]. Quando estimam, costumam basear-se em estimativas passadas, mesmo sabendo que elas podem estar incorretas (no sabem tambm precisar o quanto elas esto incorretas). H gerentes que se recusam a estimar somente por julgarem perda de tempo, uma vez que correm o risco de obter resultados incorretos e, portanto, estarem desperdiando tempo.
Exemplos de SPA/SPI so: CMM, CMMI, BootStrap, ISO9000, ISO/IEC15504, ISO12207, entre outros.
12
Boas estimativas de custo, esforo e prazo de software requerem um processo ordenado que defina a utilizao de mtricas de software, mtodo e ferramenta de estimativa. As empresas de software, de forma geral, no detm conhecimentos e recursos para isso [Vigder1994]. Estimar, medir e controlar um projeto de software so tarefas difceis, pois o desenvolvimento de software uma atividade criativa e intelectual, com muitas variveis envolvidas (como metodologias, modelos de ciclo de vida, tcnicas, ferramentas, tecnologias, recursos e atividades diversas). Os gerentes inexperientes tentam cumprir prazos dando a mxima velocidade na fase inicial e esto despreparados para os momentos de impasse, quando os ajustes so inevitveis. A dinamicidade do processo de software dificulta tambm o gerenciamento efetivo de projetos de software, devido s alteraes constantes nos planos de projetos, redistribuio de atividades, incluso/excluso de atividades, adaptao de cronogramas, realocao de recursos, novos acordos com os clientes, entregas intermedirias no previstas etc. Um projeto de software tambm deve adaptar-se ao ambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades do pessoal ou equipe. Outros fatores ainda agravam os problemas de gerenciamento de projetos de software em empresas de pequeno e mdio porte, tais como: inexistncia de um processo definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura em processos, pouco treinamento em engenharia de software, imaturidade metodolgica, crescimento ocorrido por demanda, falta de experincia administrativa por parte dos gerentes e diretores e falta de definio das metas organizacionais. 1.4 ESTRUTURA DO MDULO
Alm deste captulo introdutrio, este mdulo est organizado em mais cinco captulos e dois apndices. O captulo 2 aborda padres, normas e modelos que definem boas prticas para a gerncia de projetos de software. Este captulo tambm prope um modelo com elementos essenciais para a construo de um processo de gerncia de projetos. A inteno deste captulo apresentar ao aluno conceitos que julgamos importante para a criao de um bom processo de gerncia de projetos de software. Os captulos 3, 4 e 5 apresentam um exemplo de processo de gerncia de projetos de software para empresas de pequeno e mdio porte. Nestes captulos ser apresentado o ProGer Processo de Gerncia de Projetos de Software, que um processo que pode ser aplicado para empresas de pequeno e mdio porte. Estes trs captulos objetivam mostrar ao aluno um exemplo de como um processo de gerncia de projetos de software que pode ser utilizado para melhorar o desempenho de uma empresa. Por fim, o captulo 6 realiza uma concluso geral sobre os temas abordados neste mdulo.
Introduo
13
EXERCCIOS DE FIXAO:
1. Tente relembrar, sem consultar o texto deste captulo, quais so as principais dificuldades encontradas pelas empresas de software para gerenciar seus projetos. 2. No frum virtual, coloque algumas consideraes sobre a dificuldade da gerncia de projetos. Voc concorda com as dificuldades citadas neste captulo? Existem outras dificuldades que voc j observou e queira compartilhar conosco? 3. No incio do captulo foi apresentada uma pesquisa realizada por Gibbs em 1994. Esta pesquisa demonstrou que a Engenharia de Software, em diversos aspectos, ficou estagnada desde 1960, quando foi publicado o texto The Software Crisis. Os mesmos problemas apresentados em 1960 eram os de 1994. Voc acha que existe algum fator histrico que merea destaque para esta estagnao da Engenharia de Software? Voc acredita que este quadro ainda o mesmo atualmente (dez anos depois)? Vamos discutir isso no frum? 4. Por que os modelos e padres para SPA/SPI aconselham que se inicie o processo de melhoria com a gerncia de projetos? Por que as metodologias de desenvolvimento esto sendo colocadas como uma etapa seguinte? 5. Gerenciar projetos de software diferente de gerenciar projetos de manufatura? Por que voc tem esta opinio? Compartilhe suas idias no frum virtual. 6. Neste captulo foi apresentada uma pesquisa do Standish Group, de 1995, sobre alguns problemas da indstria de software dos Estados Unidos. Em 2001 foi realizada uma pesquisa similar. Voc conhece esta pesquisa? Os indicadores continuam os mesmos? Como se comportou a indstria de software dos Estados Unidos de 1995 para 2001? Compartilhe esta pesquisa e sua opinio no frum virtual. 7. Voc concorda com a afirmao da seo 1.1 que diz que um projeto cria um produto, servio ou resultado NICO? (Pense um pouco a respeito e depois leia a seo 1.2 do PMBOK). 8. Voc concorda com a afirmao da seo 1.1 que diz que um projeto deve ter caracterstica TEMPORAL? (Pense um pouco a respeito e depois leia a seo 1.2 do PMBOK). 9. Qual a diferena entre escopo do projeto e escopo do produto/servio? (pesquise no PMBOK).
14
2
MODELOS, PADRES E NORMAS E A GERNCIA DE PROJETOS
Os estudos realizados na dcada de 1990 sobre gerenciamento de projetos de software deixaram evidente que as prticas de gerenciamento de projetos devem ser melhoradas para que os projetos de software tenham sucesso. Dada esta preocupao, muitos modelos e normas para SPA/SPI evoluram, principalmente com a incluso de prticas gerenciais para os projetos de software; exemplos so: CMM [Paulk1993] para CMMI [CMMI:2000]; o adendo norma ISO12207 [ISO12207:1995] em 2001 [ISO12207:2000] e os novos processos de gerenciamento inseridos na ISO/IEC15504 no decorrer de sua confeco. Contudo, Machado [Machado2001] demonstrou recentemente que apesar das pesquisas evidenciarem que o problema da indstria de software mais gerencial do que tcnico, a gerncia de projetos no est sendo considerada como deveria. Atravs da comparao das prticas de gerenciamento propostas nos padres e normas para SPA/SPI com as contidas no PMBOK Project Management Body Knowledge3 [PMBOK2000], concluiu-se que os requisitos de gerenciamento de projeto no esto representados devidamente nos modelos [Machado2001]. O gerenciamento de projeto de software tem sido priorizado h pouco tempo pelas organizaes que definem padres e normas para software. A ISO/IEC15504 quem aborda o gerenciamento de projetos de software de forma mais completa [Wang1999]. Ela estabelece um conjunto de prticas bsicas que devem ser seguidas para o sucesso do gerenciamento de projetos de software. Desta forma, optamos por destacar neste captulo os processos de gerenciamento de projetos proposto pela ISO/IEC15504. Este captulo tambm apresentar as reas de conhecimento do PMBOK.
2.1
PROCESSOS DE GERENCIAMENTO DA ISO/IEC15504

3
O PMBOK e suas reas de conhecimento est em detalhes nas sees seguintes. O texto completo do PMBOK se encontra no material complementar do ambiente virtual.
Modelos, Padres e Normas e a Gerncia de Projetos
15
Em 1993, um grupo de trabalho conjunto da ISO/IEC-International Organization for Standardization/International Electrotechnical Commission estabeleceu um projeto denominado SPICE-Software Process Improvement and Capability Evaluation [Dorling1993], que objetivava chegar a um consenso entre os diversos mtodos de avaliao do processo de software. Este projeto, posteriormente, gerou o relatrio tcnico ISO/IEC15504 [ISO/IEC15504:1-9:1998]. A ISO/IEC15504 atualmente uma norma que representa um padro internacional emergente que estabelece um framework para construo de processos de avaliao e melhoria do processo de software. Este framework pode ser utilizado pelas empresas envolvidas em planejar, gerenciar, monitorar, controlar e melhorar a aquisio, fornecimento, desenvolvimento, operao, evoluo e suporte do software. A ISO/IEC15504 no um mtodo isolado para avaliao e sua caracterstica genrica permite que possa ser utilizada em conjunto com uma variedade de mtodos, de tcnicas e de ferramentas. Nove documentos compem a ISO/IEC15504. Alguns tm carter normativo (como a ISO/IEC15504-2, ISO/IEC15504-3 e ISO/IEC15504-9) e outros possuem carter informativo (como a ISO/IEC15504-1, ISO/IEC15504-4, ISO/IEC15504-5, ISO/ IEC15504-6, ISO/IEC15504-7 e ISO/IEC15504-8). A ISO/IEC15504-2 define um modelo de referncia de processo e um modelo de capacitao do processo (Figura 2.1) que pode compor a base para a definio e avaliao de um processo de software. Este modelo de referncia possui uma abordagem bidimensional.
Processos do Ciclo de Vida Categoria
Nvel 5 4 3 2 1 0
CUS
ENG
SUP
MAN
ORG
.............
Processo
Nome dos Atributos Processo Otimizado Atributos de mudana do processo Atributos de melhoria continua Processo Previsvel Atributos de medida do processo Atributos de controle do processo Processo Estabelecido Atributos de definio do processo Atributos de recursos do processo Processo Gerenciado Atributos de gerencimento do desempenho Atributos do gerenciamento de artefatos Processo Executado Atributos de desempenho do processo Atributos de melhoria continua Processo Incompleto
Dimenso de Processo
Dimenso de Capacidade
FIGURA 2.1 As dimenses do modelo de referncia da ISO/IEC15504 A primeira dimenso auxilia os engenheiros de processo na definio dos processos necessrios em uma empresa, assim como sua adequao
16
ISO/IEC15504. A segunda dimenso, similar ao CMM, tem por objetivo determinar a capacidade do processo da empresa, avaliando-o atravs de um conjunto de atributos preestabelecidos. Os atributos de processo esto agrupados nos nveis de capacidade e podem ser aplicados em todos os processos descritos na organizao para determinar a maturidade do processo. Cinco grupos de processos so definidos pela ISO/IEC15504-2: 1. Fornecedor-Cliente (CUS-Custormer-Supplier): so os processos que de alguma forma impactam diretamente o cliente, dentre eles o suporte para desenvolvimento e transaes de software para o cliente, fornecimento de operaes corretas e uso do produto de software ou servio; 2. Engenharia (ENG-Engineering): esta categoria agrupa os processos que especificam, implementam e mantm o produto de software, sua relao com o sistema e a documentao do cliente; 3. Suporte (SUP-Support): so processos que podem ser empregados em algum dos outros processos e em vrios pontos no ciclo de vida do software, objetivando dar suporte a eles; 4. Gerenciamento (MAN-Management): so processos que contm prticas gerenciais que podem ser utilizadas por algum que gerencia algum tipo de projeto ou processo dentro do ciclo de vida do software; 5. Organizao (ORG-Organization): so processos que estabelecem as finalidades dos processos de desenvolvimento e da organizao, do produto e dos recursos que, quando utilizados por projetos na organizao, realizaro as metas do negcio. A categoria de processo MAN (Management process category) quem estabelece os processos de gerenciamento para a empresa, que esto subdivididos em quatro grupos: MAN.1 Processo de gerenciamento organiza, monitora e controla o incio e o desempenho de qualquer processo ou funo dentro da empresa, alcanando as metas do negcio de maneira efetiva; MAN.2 Gerenciamento de projetos identifica, estabelece, coordena e monitora atividades e recursos necessrios para que um projeto realize um produto ou servio de acordo com seus requisitos; MAN.3 Gerenciamento da qualidade monitora a qualidade dos produtos e servios realizados pelos projetos e garante que eles satisfaam ao cliente; MAN.4 Gerenciamento de riscos identifica e mitiga os riscos dos projetos, continuamente, atravs do ciclo de vida de um projeto.
17
Apesar dos quatros agrupamentos estarem envolvidos no gerenciamento de projetos, vamos descrever apenas o grupo MAN.2, que est subdividido em 12 prticas bsicas: MAN.2.BP1 Define o escopo do trabalho, ou seja, o trabalho que deve ser feito por um projeto, estabelecendo que metas devem e podem ser atingidas considerando os recursos disponveis e as restries; MAN.2.BP2 Determina a estratgia de desenvolvimento, avaliando as opes disponveis para alcanar as metas do projeto, estabelecendo os riscos e as oportunidades que a estratgia deve considerar; MAN.2.BP3 Seleciona um modelo de ciclo de vida para o projeto que apropriado ao escopo, magnitude e complexidade do projeto; MAN.2.BP4 Estabelece as tarefas estimando seu tamanho e os recursos necessrios para completar o trabalho, avaliando as opes disponveis para alcance das metas do projeto e levando em considerao os riscos e as oportunidades; MAN.2.BP5 Estabelece a estrutura de diviso do trabalho, as entregas e a seqncia das tarefas, levando em conta os recursos requeridos e a estratgia adotada; MAN.2.BP6 Identifica os requisitos da infra-estrutura, ou seja, os elementos do ambiente e os recursos humanos necessrios para suportar a estratgia e a execuo do projeto; MAN.2.BP7 Estabelece o cronograma do projeto, baseado na estrutura de diviso do trabalho, estimativas realizadas e elementos da infra-estrutura considerados; MAN.2.BP8 Aloca responsabilidades, identificando os indivduos especficos e os grupos necessrios para garantir a realizao do que foi acordado no projeto; MAN.2.BP9 Identifica as interfaces entre os elementos no projeto e com outros projetos e unidades organizacionais; MAN.2.BP10 Estabelece e implementa os planos de projeto, fornecendo um mecanismo para garantir que os projetos sero formalmente desenvolvidos, implementados, mantidos e estando disponveis para todos os envolvidos no projeto; MAN.2.BP11 Compara o planejado no plano de projeto com o que est sendo executado; MAN.2.BP12 Corrige os desvios quando os objetivos do projeto no esto sendo alcanados.
18
Os processos de gerenciamento comeam a ser necessrios na ISO/IEC15504 somente a partir do nvel 2 de capacidade e esto distribudos conforme mostra a Tabela 2.1. TABELA 2.1 Distribuio dos processos de gerenciamento nos nveis de capacidade da ISO/IEC15504
Nveis de Capacidade 1. Processo Executado 2. Processo Gerenciado 3. Processo Estabelecido 4. Processo Previsvel 5. Processo Otimizado MAN.1, MAN.2, MAN.3, MAN.4 MAN.1, MAN.2 MAN.2, MAN.3, MAN.4 MAN.3 Categorias de Processo de Gerenciamento
2.2
PMBOK
O PMI Project Management Institute uma associao de profissionais de gerenciamento de projetos que existe desde 1969. Esta associao criou em 1986 a primeira verso do PMBOK Project Management Body of Knowledge4. O PMBOK um guia que descreve a somatria de conhecimento e as melhores prticas dentro da profisso de gerenciamento de projetos. um material genrico que serve para todas as reas de conhecimento, ou seja, tanto para construo de um edifcio como para a produo de software. A meta do gerenciamento de projetos, segundo o PMBOK, conseguir exceder as necessidades e expectativas dos stakeholders. Todavia, como j visto no captulo 1, satisfazer ou exceder estas necessidades envolve um balanceamento entre as vrias demandas concorrentes em relao: escopo, tempo, custo e qualidade (objetivos do projeto); stakeholders com necessidades e expectativas diferenciadas; e requisitos identificados (necessidades) e requisitos no identificados (expectativas).
O PMBOK [PMBOK2000] organiza os processos de gerenciamento de projetos em cinco grupos (figura 2.2): processos de inicializao, processos de planejamento, processos de execuo, processos de controle e processos de finalizao.
O PMBOK o material mais importante que foi gerado pelo PMI, contudo, esta instituio possui diversos outros documentos e relatos que so bastante relevantes para a gerncia de projetos. Para se aprofundar no assunto, voc pode consultar o material complementar do ambiente virtual ou visitar o site http://www.pmi.org/ .
42
19
FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK Os processos de inicializao autorizam o incio do projeto ou de uma fase do projeto. Os processos de planejamento definem e refinam os objetivos do projeto,
Processos de Inicializao Processos de Planejamento
Processos de controle
Processos de execuo
Processos de finalizao
selecionando as melhores alternativas para realiz-lo. Os processos de execuo coordenam pessoas e outros recursos para a realizao do projeto, baseando-se no planejamento. Os processos de controle monitoram e medem o progresso do que est sendo executado, com o intuito de tomar aes corretivas quando necessrias. Os processos de finalizao formalizam o aceite e a finalizao do projeto ou de uma fase do projeto. Os processos do PMBOK esto organizados por reas de conhecimento, que se referem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentro destas reas de conhecimento os cinco grupos de processos acima descritos podem ocorrer. A figura 2.3 mostras as 9 reas de conhecimento do PMBOK. A seguir descreveremos os processos de cada rea de conhecimento do PMBOK. Todos os processos descritos, das reas abaixo, interagem uns com os outros e tambm com os processos das demais reas de conhecimento. Cada processo pode envolver esforo de um ou mais indivduos ou grupos de indivduos, dependendo das necessidades do projeto. Cada processo, geralmente, ocorre pelo menos uma vez em cada fase do projeto.
2.2.1 Gerncia de integrao de projetos
20
A gerncia de integrao engloba os processos necessrios para garantir que os vrios elementos de um projeto sejam propriamente coordenados. Objetiva realizar as negociaes dos conflitos entre objetivos e alternativas do projeto com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a execuo do plano de projeto e o controle geral das mudanas. Essa rea de processo incluiu os seguintes processos principais: desenvolvimento do plano do projeto - agregar os resultados dos outros processos de planejamento, construindo um documento coerente e consistente; execuo do plano do projeto - levar a cabo o projeto atravs da realizao das atividades nele includas; controle geral de mudanas - coordenar as mudanas atravs do projeto inteiro.
FIGURA 2.3 reas do gerenciamento de projetos do PMBOK
Gerncia de Projeto
Gerncia de Integrao
Gerncia de Escopo
Gerncia de Tempo
Gerncia de Custo
Gerncia de Qualidade
Gerncia de Recursos Humanos
Gerncia de Comunicao
Gerncia de Risco
Gerncia de Aquisio
2.2.2 Gerncia de escopo de projetos A gerncia do escopo do projeto inclui os processos requeridos para assegurar que o projeto inclua todo o trabalho necessrio, e to somente o trabalho necessrio, para complementar de forma bem sucedida o projeto. A preocupao fundamental compreende definir e controlar o que est ou no includo no projeto. Essa rea de processo incluiu os seguintes processos principais:
21
iniciao - comprometer a organizao a iniciar a prxima fase do projeto; planejamento do escopo - desenvolver uma declarao escrita do escopo como base para decises futuras do projeto; detalhamento do escopo - subdividir os principais subprodutos do projeto em componentes menores e mais manejveis; verificao do escopo - formalizar a aprovao do escopo do projeto; controle de mudanas de escopo - controlar as mudanas do escopo do projeto.
2.2.3 Gerncia de tempo de projetos A gerncia de tempo do projeto objetiva garantir o trmino do projeto no tempo certo. Consiste da definio, ordenao e estimativa de durao das atividades e de elaborao e controle de cronogramas. Essa rea incluiu os seguintes processos principais: definio das atividades - identificar as atividades especficas que devem ser realizadas para produzir os diversos subprodutos do projeto; seqenciamento das atividades - identificar e documentar as relaes de dependncia entre as atividades; estimativa da durao das atividades - estimar a quantidade de perodos de trabalho que sero necessrios para a implementao de cada atividade; desenvolvimento do cronograma - analisar a seqncia e as duraes das atividades e os requisitos de recursos para criar o cronograma do projeto; controle do cronograma - controlar as mudanas no cronograma do projeto.
2.2.4 Gerncia de custo de projetos A gerncia de custo tem por objetivo garantir que o projeto seja executado dentro do oramento aprovado. Consiste no planejamento dos recursos, estimativa, oramento e controle de custos. Essa rea de processo incluiu os seguintes processos principais: planejamento dos recursos - determinar quais recursos (pessoas, equipamentos, materiais) e que quantidade de cada deve ser usada para executar as atividades do projeto; estimativa dos custos - desenvolver uma estimativa dos custos dos recursos necessrios implementao das atividades do projeto;
22
oramento dos custos - alocar as estimativas de custos globais aos itens individuais de trabalho; controle dos custos - controlar as mudanas no oramento do projeto.
2.2.5 Gerncia da qualidade de projetos A gerncia da qualidade objetiva garantir que o projeto satisfar as exigncias para as quais foi contratado. Consiste no planejamento, garantia e controle de qualidade. Essa rea de processo incluiu os seguintes processos principais: planejamento da qualidade - identificar quais padres de qualidade so relevantes para o projeto e determinar a forma de satisfaz-los; garantia da qualidade - avaliar periodicamente o desempenho geral do projeto, buscando assegurar a satisfao dos padres relevantes de qualidade; controle da qualidade - monitorar os resultados especficos do projeto para determinar se eles esto de acordo com os padres de qualidade relevantes e identificar as formas para eliminar as causas de desempenhos insatisfatrios.
2.2.6 Gerncia de recursos humanos de projetos A gerncia de recursos humanos objetiva garantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste no planejamento organizacional, alocao de pessoal e definio de equipe. Essa rea de processo incluiu os seguintes processos principais: planejamento organizacional - identificar, documentar e designar as funes, responsabilidades e relacionamentos de reporte dentro do projeto; montagem da equipe - conseguir que os recursos humanos necessrios sejam designados e alocados ao projeto; desenvolvimento da equipe - desenvolver habilidades individuais e do grupo para aumentar o desempenho do projeto.
2.2.7 Gerncia de comunicao de projetos A gerncia de comunicao tem por objetivo principal garantir a gerao adequada e apropriada, coleta, disseminao, armazenamento e disponibilizao da informao. Essa rea de processo incluiu os seguintes processos principais:
23
planejamento das comunicaes - determinar as informaes e comunicaes necessrias para os interessados: quem necessita de qual informao, quando necessitaro dela e como isso ser fornecido; distribuio das informaes - disponibilizar as informaes necessrias para os interessados do projeto da maneira conveniente; relato de desempenho - coletar e disseminar as informaes de desempenho. Inclui relatrios de situao, medio de progresso e previses; encerramento administrativo - gerar, reunir e disseminar informaes para formalizar a concluso de uma fase ou de todo o projeto.
2.2.8 Gerncia de risco de projetos A gerncia de risco objetiva maximizar os resultados de ocorrncias positivas e minimizar as conseqncias de ocorrncias negativas. Consiste na identificao, quantificao, tratamento e controle dos riscos do projeto. Essa rea de processo incluiu os seguintes processos principais: identificao dos riscos - determinar quais os riscos so mais provveis de afetar o projeto e documentar as caractersticas de cada um; quantificao dos riscos - avaliar os riscos, suas interaes e possveis conseqncias; desenvolvimento das respostas aos riscos - definir as melhorias necessrias para o aproveitamento de oportunidades e respostas s ameaas; controle das respostas aos riscos - responder s mudanas nos riscos no decorrer do projeto.
2.2.9 Gerncia de aquisio de projetos A gerncia de aquisio tem por objetivo principal obter bens e servios externos organizao executora. Consistem na seleo de fornecedores, planejamento de aquisio, planejamento de solicitao, solicitao de propostas e administrao e encerramento de contratos. Essa rea de processo incluiu os seguintes processos principais: planejamento das aquisies - determinar o que contratar e quando; preparao das aquisies - documentar os requisitos do produto e identificar os fornecedores potenciais; obteno de propostas - obter propostas de fornecimento conforme apropriado a cada caso (cotaes de preo, cartas-convite, licitao);
24
seleo de fornecedores - escolher entre os possveis fornecedores; administrao dos contratos - gerenciar o relacionamento com os fornecedores; encerramento do contrato - completar e liquidar o contrato incluindo a resoluo de qualquer item pendente.
2.3
MODELAGEM DO SISTEMA DE PROCESSOS DE EMPRESA DE SOFTWARE
Como j estudado anteriormente em outros mdulos do curso, um processo pode ser definido como um conjunto de atividades inter-relacionadas que transformam um conjunto de entradas em resultados [ISO12207:1995]. Segundo a ISO15504 [ISO15504:1-9:1998], processo de software um conjunto de processos utilizados por uma organizao de software ou um projeto de software para planejar, gerenciar, executar, monitorar, controlar e melhorar as atividades que esto relacionadas com software. O trabalho de Wang [Wang1999] apresenta um framework unificado de um sistema de processo para uma organizao de software. A figura 2.4 mostra este modelo, que est dividido em trs agrupamentos principais: o modelo do processo, o modelo de avaliao do processo e o modelo de melhoria do processo.
Modelagem do sistema de processo
Modelo do processo
Modelo de avaliao do processo
Modelo de melhoria do processo
Subsistema do processo organizacional
Subsistema do processo de desenvolvimento
Subsistema do processo de gerenciamento
Modelo de capacidade do processo
Mtodo de determinao da capacidade do processo
Modelo de melhoria baseado em avaliao
Modelo de melhoria baseado em Benchmark
Escala do desempenho da pratica
Escala da capacidade do processo
Escopo da capacidade do processo
Determinao da capacidade do processo
Agregao de capacidade do projeto
Agregao da capacidade da organizao
FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de software O modelo do processo utilizado para descrever a organizao, sua categoria, sua hierarquia, o inter-relacionamento e as instncias dos seus processos.
25
O modelo de processo descrito por [Wang1999] identifica trs conjuntos de subsistemas: processo organizacional, processo de desenvolvimento de software e processo de gerenciamento. Os processos organizacionais regulam as atividades que so geralmente praticadas em uma empresa acima do nvel de projeto. Os processos de desenvolvimento e de gerenciamento so interativos e, em paralelo, atuam sobre o projeto. O modelo de avaliao do processo serve para definir procedimentos para avaliar os pontos fortes e fracos dos processos da organizao, alm de identificar os pontos para melhoria. Atravs do modelo de melhoria do processo podem-se definir procedimentos sistemticos para uma efetiva melhoria do desempenho dos processos da empresa mudando os processos correntes ou adicionando a eles novos processos para correo ou melhoria de problemas identificados. O processo de melhoria vem a seguir do processo de avaliao e o relacionamento entre eles forma um ciclo repetitivo at o processo da organizao estar otimizado. Exemplo o plando-check-act descrito por Campos [Campos1992]. Diversos modelos, normas e padres definem certificao, avaliao e melhoria para o processo de software, entre eles podemos citar: a ISO9000 [ISO9000-3:1997], CMM/CMMI [Paulk1993] [Paulk1997] [CMMI:2000], ISO15504 [ISO15504:1-9:1998] e BootStrap [Kuvaja1993] [Kuvaja1994]. Apesar das empresas de software durante muito tempo negligenciarem a especificao e o gerenciamento de seus processos, estes sempre existiram. Porm, no h um consenso de que tipo de processo de software deva ser utilizado em uma organizao, pois alguns processos se adequam melhor a certos tipos de aplicaes do que outros. Alm disso, uma empresa pode, inclusive, possuir diversos padres de processos de software sendo utilizados em projetos distintos. O reconhecimento das necessidades dos modelos de processo de software tem deixado um amplo campo de trabalho em muitas direes. As organizaes que desenvolvem software tm verificado que definindo seus processos podem melhorar sua eficcia e a qualidade dos produtos e servios que realizam. A seo seguinte apresenta um modelo que utilizaremos nos prximos captulos para definir um processo para gerncia de projetos para uma empresa de software, o ProGer - Processo de Gerncia de Software.
2.4
ELEMENTOS ESSENCIAIS PARA CRIAR UM PROCESSO DE GERNCIA DE PROJETOS
26
Algumas propostas de processo para gerncia de projetos de software podem ser encontradas na literatura. O fluxo de gerncia de projetos do RUP [Rational Unified Process] um exemplo. Contudo, estes processos no devem ser adotados em uma empresa sem que se leve em considerao alguns outros elementos que julgamos essenciais. Desta forma, propomos que ao criar um processo de gerncia de projetos para uma empresa de software deve-se considerar seis elementos essenciais, como mostra a Figura 2.5: a poltica organizacional, os padres, o processo de gerenciamento, os procedimentos, os treinamentos, e as ferramentas5.
Poltica Organizacional Padres
restringe o processo
Processo de gerenciamento de projetos de software

implementado atravs de
Procedimentos
so apoiados por
Treinamento
Ferramentas de gerenciamento de projetos de software
FIGURA 2.5 Modelo para criao de processo de gerenciamento de projetos de software A poltica organizacional estabelece as leis e as regras que governam ou restringem as operaes da empresa. Ela identifica os requisitos aceitveis do processo e/ou formas de se realizar o projeto. A poltica organizacional estabelece tambm as metas e os objetivos que a organizao deseja alcanar. Os padres definem as operaes e os critrios de aceitao para a execuo de servios e produtos da empresas. Os padres e normas para SPA/SPI e as metodologias podem, por exemplo, ser utilizados para a definio dos padres da organizao.
Esta recomendao se aplica tambm a outras reas de processo e no somente a gerncia de
projetos.
27
Um processo de gerenciamento de projetos de software descreve como a organizao gerencia a execuo de seus servios e produtos, de acordo com a poltica organizacional e os padres adotados. Nos captulos seguintes definiremos o ProGer, que um modelo para gerncia de projetos de software. O ProGer pode auxiliar as empresas de software na organizao inicial de seu negcio atravs do uso de artefatos de alto nvel e de baixa complexidade, em conjunto com um modelo de ciclo de vida para os projetos e o estabelecimento de fluxos de trabalho. Os processos so implementados atravs de procedimentos. Os fluxos de trabalho, por exemplo, podem especificar esses procedimentos, ou seja, as instrues passo-a-passo de como o processo deve ser executado. A poltica organizacional que restringe e expande o processo de gerncia de projetos, adaptando-o realidade da empresa e estabelecendo procedimentos especficos, dependendo do projeto. As ferramentas determinam algum apoio automatizado para os procedimentos do processo, seja auxiliando na execuo das atividades como para obteno de mtricas para posterior avaliao do processo. Os treinamentos possibilitam dar aos recursos humanos da empresa o conhecimento e habilidades necessrias para executarem os procedimentos do processo. 2.5 CONSIDERAES
Como j dito anteriormente neste captulo, os padres e normas para SPA/SPI podem ser utilizados com o intuito de definir, avaliar e melhorar os processos de uma empresa. Todavia, apesar da sua importncia, eles ainda esto sendo pouco considerados pelas empresas [Lindvall2000]. Diversos motivos dificultam o uso destes padres, dentre eles o fato de que a definio e uso de um processo de software envolvem uma complexa inter-relao de fatores organizacionais, culturais, tecnolgicos e econmicos. A complexidade destes modelos tambm dificulta sua implantao em empresas de pequeno porte, j que foram construdos para o mbito de empresas estruturadas e estabilizadas. Porm, acreditamos que a grande ameaa implantao destes padres e normas, nas empresas, o dia-a-dia da empresa que absorve praticamente todos os recursos existentes. Sendo esse um projeto interno, de longo prazo e com resultados tambm de longo prazo, h uma tendncia acomodao, fazendo com que as atividades sejam proteladas por diversas vezes at a desistncia.
28
No que se refere ao gerenciamento de projetos de software especificamente, estamos de acordo com as concluses realizadas nos trabalhos [Fernandes1989] e [Maidantchik1999]: apesar do esforo da comunidade de engenharia de software em definir modelos e padres para a construo de um efetivo processo de gerenciamento de projetos, a maioria das empresas ainda sente dificuldade em definir os seus processos e no gerenciam os seus projetos de forma satisfatria. O gerenciamento de projetos de software , de fato, pouco abordado e praticado e, porque no dizer, negligenciado. Os ambientes tradicionais das empresas tm dado suporte, em geral, somente engenharia, assumindo um processo implcito e tendo como foco principal o produto. Acreditamos que esta viso limita as empresas no que diz respeito tomada de decises, ao estabelecimento e obteno de metas organizacionais, determinao de pontos para melhoria, estipulao de prazos para entrega de produtos e at mesmo obteno de uma certificao. O PMBOK e os modelos de SPA/SPI podem ser utilizados para criar um processo padro para gerenciamento de projetos de software. Estes modelos renem boas prticas para as empresas. Contudo, a implantao destes padres exige um investimento importante dos envolvidos, para conceber um processo que venha alavancar o negcio, facilitar a vida dos envolvidos e no criar burocracia somente para atender aos requisitos descritos no modelo. Alm disso, estes modelos descrevem o que deve ser feito e no como faz-lo. Algumas iniciativas j foram realizadas com o intuito de descrever o como utilizar normas e padres de SPA/SPI em uma empresa. Contudo, estes frameworks acabam sendo to complexos quanto os modelos que os originou e esto descritos tambm para o mbito de empresas estruturadas. Os prximos captulos deste mdulo apresentam um exemplo de processo para gerncia de projetos de software que foi construdo considerando os seis elementos essenciais apresentados neste captulo. O captulo 3 define a poltica organizacional e os padres adotados. O captulo 4 traz o processo propriamente dito, com seu modelo de ciclo de vida para os projetos, fluxos de trabalho, artefatos, stakeholders, mtricas, etc. O captulo 5 relaciona algumas ferramentas que podem ser utilizadas em conjunto com o processo.
29
EXERCCIOS DE FIXAO:
1. Considerando o ambiente em que trabalha, que prticas bsicas da ISO/IEC15504 de gerncia de projetos voc acredita estar satisfazendo? 2. Considerando que uma das maiores dificuldades da gerncia de projetos de software a constante mudana do escopo, leia a rea de conhecimento Gesto de Escopo do PMBOK e coloque a sua opinio sobre o que acredita ser aplicvel para empresas de software no frum virtual. 3. Considerando as 9 reas de conhecimento do PMBOK, escolha a que julga mais relevante para o seu ambiente profissional. Leia atentamente esta rea no PMBOK e troque idia no frum virtual de como voc poderia institucionaliz-la em sua empresa (ou departamento). 4. Voc concorda com os elementos essenciais para a criao de um processo para gerncia de projetos? Que elementos voc julga estar faltando? Que elementos voc desconsideraria? (Coloque a sua opinio no frum virtual).
3
POLTICA ORGANIZACIONAL E PADRES ADOTADOS PARA A DEFINIO DO PROGER
Este captulo apresenta a poltica organizacional e as metas adotadas para a criao do processo de gerncia de projetos de software, denominado ProGer. Este captulo estabelece dois dos seis elementos essenciais definidos na seo 2.4 deste mdulo. 3.1 POLTICA ORGANIZACIONAL CONSIDERADA PARA O PROGER
Como visto no captulo anterior, a poltica organizacional estabelece as leis e regras que governam ou restringem as operaes da empresa de software. Ela identifica os requisitos aceitveis do processo e/ou formas de se realizar o projeto. A poltica organizacional estabelece tambm as metas e os objetivos que a empresa deseja alcanar. De forma simplista, vamos definir a poltica organizacional baseado em dois aspectos: (1) caracterizao da empresa e (2) metas que a empresa pretende atingir com a gerncia de projetos. 3.1.1 Caracterizao da empresa O modelo de processo para gerenciamento de projetos de software apresentado neste mdulo dever ser aplicvel para empresas de pequeno e mdio porte. A classificao do porte de uma empresa de software pode ser realizada considerando diversos fatores, entre eles podemos citar: faturamento, fora de trabalho e comercializao anual bruta. Ns adotamos a classificao do porte da empresa baseada na fora de trabalho, dada pelo MCT-Ministrio da Cincia e Tecnologia [MCT]: micros de 1 a 10 pessoas; pequenas de 11 a 50 pessoas; mdias de 50 a 100 pessoas; grandes mais de 100 pessoas.
Poltica Organizacional e Padres Adotados para a definio do ProGer
31
Ns optamos por considerar estas classes de empresas de software devido ao fato de serem a grande maioria. A Figura 3.1 apresenta um grfico, tambm retirado do [MCT], que mostra a predominncia deste tipo de organizao com percentuais superiores a 80%, desde 1995.
41 42
43 35 36 30 38
1993 1995 1997 1999
Percentual
20 13 8 6 7 7
19 15
20
Micro
Pequena
Mdia
Grande
FIGURA 3.1 Porte das empresas, segundo a fora de trabalho efetiva O MCT ainda preconiza que se forem considerados os servios terceirizados, que so muito comuns nas reas de produo de servios e produtos de software, o percentual de empresas de grande porte diminui significativamente, aumentando o rol de empresas de pequeno e mdio porte. Estudos realizados tambm em outros pases, como o de [Standish1995], tambm estabeleceram a predominncia de empresas de pequeno e mdio porte no setor computacional. Outras motivaes nos fizeram optar por abordar, para o nosso exemplo, as empresas de pequeno e mdio porte. Segundo Laitinen [Laitinen2000], as empresas desta classe so as que mais urgentemente necessitam de formalizao de procedimentos para gerenciamento e controle de seus projetos. Tambm afirma que, a utilizao de padres e normas para SPA/SPI est sendo pouco considerada por esta classe de empresas [Lindvall2000]. Devido ao fato destes modelos terem sido originalmente desenvolvidos para o mbito de empresas bem estruturadas e departamentalizadas, ou seja, tipicamente para o mbito de grandes empresas, isso dificulta ainda mais a orientao para empresas de pequeno e mdio porte [Belloquim1999]. Outros fatores ainda agravam os problemas de gerenciamento de projetos de software em empresas de pequeno porte, tais como: inexistncia de um processo
32
definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura em processos, pouco treinamento em engenharia de software, imaturidade metodolgica, crescimento ocorrido por demanda, falta de experincia administrativa por parte dos gerentes e diretores e falta de definio das metas organizacionais. Consideramos tambm que a empresa para a qual estamos criando o processo de gerncia de projetos atua no mercado da seguinte forma: desenvolve produtos baseados nas necessidades especficas dos clientes, tipo atelier; possui produtos prprios que so customizados para as necessidades especficas dos clientes; presta servios de instalao de sistemas de outras empresas.
Outras caractersticas que consideramos para esta empresa: possui projetos de curta, mdia e longa durao; no utiliza metodologia para desenvolvimento de software; possui uma diretoria comprometida em melhorar o processo de software e introduzir padres.
3.1.2 Metas pretendidas com a gerncia de projetos As principais metas que pretendemos alcanar com a implantao do processo de gerncia de projetos seriam tornar possvel (atravs de um modelo simplificado de processo de gerenciamento de projetos de software) obter em uma empresa de pequeno e mdio porte: 3.2 melhoria da satisfao do cliente; melhoria da qualidade dos produtos gerados; melhoria da qualidade do processo; melhoria do gerenciamento dos recursos humanos; melhoria da comunicao interna e externa da empresa; melhoria do desempenho das estimativas de esforo, custo e prazo; melhoria do estabelecimento das metas organizacionais; melhoria na identificao dos riscos.
MODELOS, NORMAS E PADRES UTILIZADOS PARA A DEFINIAO DO PROGER
O ProGer, modelo que ser apresentado no prximo captulo, foi concebido considerando os padres da engenharia de processo e do gerenciamento de projetos. Foi especificado tendo como base os modelos e padres de SPA/SPI,
33
principalmente, a ISO15504 [ISO15504:1-9:1998] e o CMMCapability Maturity Model [Paulk1993], as metodologias para desenvolvimento de software (como o RUPRational Unified Process [Philippe1998] e o OPEN Process [Graham1999]), os procedimentos e normas para gerenciamento de projetos (como o PMBOK-Project Management Body of Knowledge [PMBOK2000], TQC-Total Quality Control [Campos1992] e [Royce1998]) e nos estudos empricos realizados em empresas de software de pequeno e mdio porte. Inicialmente para a especificao do ProGer, realizamos um estudo vertical nas normas e padres para SPA/SPI, considerando somente o gerenciamento de projetos para a construo de nosso modelo padro. Contudo, ns observamos atravs de estudos empricos que os padres e normas para SPA/SPI eram insuficientes como insumo bsico para a definio de um modelo padro para o gerenciamento de projetos em uma empresa. Um trabalho que enfatiza esta observao apresentado por Machado [Machado2001] que apresenta a relao das reas de conhecimento do PMBOK em comparao com dois importantes modelos, o CMM e a ISO/IEC15504 (ver tabela 3.1). Machado [Machado2001] afirma, e ns concordamos com ele, que ainda temos muito que evoluir em relao s prticas de gerncia para alcanarmos o conhecimento contido no PMBOK. Desta forma, passamos a considerar os processos descritos no PMBOK para o ProGer. Porm, apesar do PMBOK ser um guia mais completo na rea de gerenciamento de projetos ele no considera as peculiaridades da execuo de servios e produtos de software. Ns, ento, unificamos estes dois universos em um meta-processo que levou em considerao a simplicidade e facilidade para ser utilizado em empresas de pequeno e mdio porte. A seguir mostraremos uma tabela comparativa conhecimento do PMBOK, o CMM e a ISO/IEC15504. entre as reas de
34
TABELA 3.1
Comparao entre as reas de conhecimento do PMBOK, o CMM e a ISO/IEC15504

CMM Gerncia de projeto integrada Planejamento de acompanhamento Gerncia de requisitos Acompanhamento e controle. Mas, no enderea especificamente essa questo Acompanhamento e controle. Mas, no enderea especificamente essa questo Gerncia de Contratos com fornecedores ISO/IEC15504 Gerncia organizacional Gerncia de projeto Gerncia de Requisitos Gerncia de projeto. Mas, no enderea especificamente essa questo. Gerncia de projeto. Mas, no enderea especificamente essa questo. No tem processos que trate especificamente essa questo. Ela coberta na norma pela Aquisio e Fornecimento e gerenciada da mesma forma que um projeto interno organizao
PMBOK Integrao Escopo Tempo
Custo
Aquisio
Recursos Humanos
A prpria concepo do modelo diz que devem Recursos Humanos se ter habilidades para executar, mas no Gerncia do Conhecimento menciona explicitamente a necessidade de gerenciamento de recursos humanos atravs dos projetos da organizao Gerncia de Configurao cobre parcialmente esse processo. A prpria concepo do modelo diz que os processos devem ser comunicados, mas no menciona explicitamente a necessidade de comunicao dos produtos dos projetos para todos os envolvidos Gerncia de Risco Garantia de qualidade de produto e processo Gerncia de Configurao cobre parcialmente esse processo. Mas, no menciona explicitamente esse processo
Comunicao
Risco Garantia de Qualidade
Gerncia de Risco Gerncia da Qualidade
35
EXERCCIOS DE FIXAO:
1. Que outros elementos voc consideraria para definir a poltica organizacional para a construo de um processo de gerncia de projetos de software? Voc acha que a caracterizao da empresa e as metas (como apresentado neste captulo) so suficientes? Discuta no frum virtual suas sugestes e opinies.
4
PROGER: PROCESSO DE GERNCIA DE PROJETOS DE SOFTWARE
Este captulo apresenta o ProGer - Processo de Gerncia de Projetos de Software, que um exemplo de modelo de processo para gerncia de projetos de software para pequenas e mdias empresas de software. Este modelo pode auxiliar as empresas de software na organizao inicial de seu negcio. O ProGer est apresentado neste captulo atravs de: um modelo de ciclo de vida para os projetos (seo 4.1); da definio dos stakeholders (seo 4.2); da definio dos fluxos de trabalho (seo 4.4); dos artefatos gerados no processo (seo 4.3) e de sugestes de estimativas e mtricas para avaliao do desempenho da execuo dos projetos (seo 4.4). Ns objetivamos com este captulo fornecer um exemplo prtico de como se pode definir um processo para a gerncia de projeto de software de forma organizada em uma empresa de software. 4.1 MODELO DE CICLO DE VIDA PARA PROJETOS DE SOFTWARE
Segundo o PMBOK [PMBOK2000], um modelo de ciclo de vida para projetos tem por objetivo definir o incio e o fim de um projeto. Este modelo pode ser dividido em fases e geralmente aborda dois aspectos principais: (1) que trabalho deve ser feito em cada fase, e (2) quem deve estar envolvido em cada fase. No que se refere aos projetos de software, diversos modelos de ciclo de vida j foram descritos, alguns exemplos so: o modelo espiral [Boehm1988] e o modelo baseado em contrato [Graham1999]. O PMBOK [PMBOK2000] reconhece estes modelos como sendo representativos para o desenvolvimento de projetos de software. Como tal, eles esto muito focados na construo de um produto ou servio de software, isto , esto fortemente associados aos aspectos da engenharia e desconsideram etapas do projeto que antecedem e sucedem a confeco do produto propriamente dito. Estas etapas so importantes para que uma empresa possa realizar uma avaliao mais eficaz do projeto.
PROGER: Processo de Gerncia de Projetos de Software
37
Ns definimos um modelo de ciclo de vida para projetos de software identificando fases desconsideradas nos modelos tradicionais, ou mesmo considerados superficialmente, como o caso do RUP-Rational Unified Process. O ProGer est dividido em cinco fases distintas (Figura 4.1): a prospeco, a proposta, a execuo, a garantia e o encerramento. Em todas as fases devem ser aplicadas as etapas do modelo de processo para gerenciamento de projetos proposto pelo PMBOK [PMBOK2000]. Um projeto de software pode ser iniciado em qualquer uma das fases, com exceo do encerramento. permitido que fases possam ser eliminadas do projeto, isto , no h imposio de um fluxo rgido a ser seguido. A seguir, descreveremos cada uma das fases do modelo de ciclo de vida. Os artefatos gerados em cada fase esto representados na seo 4.1 deste captulo. Prospeco
Proposta
Execuo
Garantia
Encerrament o FIGURA 4.1 Modelo de ciclo de vida de projetos de software A fase de prospeco o perodo do ciclo de vida do projeto no qual so identificadas as necessidades de um cliente, ou uma demanda de mercado percebida pela empresa. A construo de um prottipo para uma demanda observada pela empresa um exemplo de atividade desta fase. A caracterstica principal desta fase a ausncia de um pedido formal por parte de um cliente, isto , uma requisio comercial. Nesta fase j se inicia o esforo tcnico e comercial da empresa. Palestras sobre produtos, construo de prottipos e levantamento de requisitos so exemplos de atividades que podem ocorrer nesta fase. Os elementos da empresa que podem estar envolvidos nesta etapa so: gerentes, diretores e tcnicos.
38
Considerando os processos de gerenciamento do PMBOK [PMBOK2000], a inicializao desta fase dada por requisies informais de clientes, solicitao de apresentao de produtos e identificao de uma demanda aprovada pela diretoria da empresa. O planejamento desta fase bastante diverso, podendo ir desde simples agendamentos de reunies at a confeco de planos de projeto para execuo de um prottipo. A execuo determinada por palestras, apresentao de produtos e construo de prottipos. A finalizao ocorre quando o cliente envia um pedido formal para a execuo de um servio ou produto, o cliente avisa que no deseja o que foi apresentado ou a empresa estabelece a continuidade ou descontinuidade do esforo para uma demanda que foi observada. Na fase de proposta, ocorre a formalizao de uma proposio da empresa para um determinado cliente interno ou externo. As caractersticas principais desta fase so: a existncia de uma requisio formal, a delimitao do escopo do projeto e o processo decisrio do que dever ser realizado. As atividades principais desta fase so a elicitao ou refinamento dos requisitos, e a confeco de propostas tcnicas e comerciais. A inicializao desta fase dada por requisies formais de clientes (um exemplo uma carta convite solicitando um produto ou servio). O planejamento desta fase estabelece quem e quando ser realizada cada atividade pertinente confeco de uma proposta tcnica e/ou comercial. A execuo de um projeto na fase de proposta determinada pela execuo de atividades como: delimitao do escopo do projeto, levantamento dos requisitos do produto ou servio, estudo de novas tecnologias, clculo de custos, elaborao de estimativas de tamanho e esforo, anlise dos riscos, etc. Os modelos para planejamento de projetos podem ser utilizados na etapa de execuo da fase de proposta. Dois exemplos destes modelos podem ser vistos em Sanches [Sanches2001] e na [ISO9000-3:1997]. A finalizao da fase de proposta ocorre quando o cliente envia um pedido solicitando a execuo ou o cancelamento da proposta para o desenvolvimento de um produto ou servio. A empresa tambm pode optar por cancelar uma proposta enviada para um cliente. A fase de execuo se caracteriza pela realizao de um escopo definido por um projeto, considerando os recursos da organizao e um cronograma especfico. Nesta fase so realizadas comumente as atividades de engenharia do produto de software. Os principais artefatos gerados so: a especificao tcnica, os artefatos de engenharia, o aceite do cliente e a comunicao ao cliente. A comunicao intensiva com os clientes pode ocorrer nesta fase devido a atrasos, reviso de cronogramas, revises tcnicas, incluso de novos requisitos, entre outros. A inicializao da fase de execuo dada por uma autorizao interna para a execuo do projeto. O planejamento prev a construo de um plano de projeto que
39
envolve atividades como: decompor requisitos, estimar em detalhes o tamanho do software, estimar recursos do projeto, elaborar cronograma e negociar compromissos. O modelo do ciclo de planejamento de projetos de software descrito pela ISO9000-3 [ISO9000-3:1997] pode ser utilizado nesta etapa. Nesta etapa prevista a confeco da estrutura de diviso de trabalho (WBS Work Breakdown Structure), ou seja, a diviso do trabalho total do projeto em fases e atividades independentes. O PMI guia a confeco de WBSs no trabalho [PMIWBS]. Nesta etapa tambm se define o modelo de ciclo de vida e a metodologia que sero utilizados no desenvolvimento do projeto. A etapa de execuo determina a realizao de atividades previstas no plano de projeto. A finalizao da fase de execuo do modelo de ciclo de vida dos projetos se d com a entrega do produto ou servio ao cliente. A obteno de um aceite do cliente (interno ou externo empresa) determina o trmino da fase de execuo. A empresa e/ou cliente tambm pode cancelar um contrato e desta forma finalizar um projeto sem que tenha sido terminada a sua execuo. Aps a execuo do projeto, o perodo de garantia estabelece um esforo tcnico, para a reviso de alguns problemas encontrados aps o trmino do projeto. A durao deste perodo depende do acordo realizado com o cliente. Os artefatos desta fase geralmente so os mesmos da fase de execuo, s que dizem respeito s modificaes e s correes do que j fora realizado e entregue ao cliente. A inicializao desta fase acontece quando a empresa obtm o aceite formal do cliente no trmino da execuo de um projeto. O planejamento prev o estabelecimento de recursos que estaro disponveis para atender o cliente na fase de garantia. Todavia, este estabelecimento prvio pode no existir. Na etapa de execuo so realizadas as atividades para adequao do produto ou servio s solicitaes do cliente. A finalizao da fase de garantia ocorre quando o prazo determinado no contrato entre a empresa e o cliente findar. No perodo de encerramento o projeto dado como finalizado. Todo o trabalho proposto foi concludo, aceito e garantido. Outros tipos de encerramentos podem ocorrer, tais como, os decorrentes de cancelamento de contratos. A inicializao desta fase ocorre quando o prazo de garantia do projeto findar ou quando um projeto em prospeco, proposta ou execuo for cancelado. No h etapas de planejamento, de execuo e de finalizao. 4.1.1 Controle e avaliao Pontos de avaliao so utilizados para sincronizar as expectativas dos stakeholders atravs do ciclo de vida do projeto [Kerzner2001] [PMBOK2000]. A definio de alguns pontos de avaliao permite a observao de problemas na
40
execuo do que fora planejado e possibilita uma ao corretiva antes do trmino do projeto. O ponto mais importante de avaliao de um projeto um milestone, que usualmente o evento em que o projeto passa de uma fase para outra. Os pontos de avaliao menores (intrafases) so altamente dependentes do projeto e da cultura organizacional [Royce1998] e so mais importantes de serem considerados principalmente na fase de execuo do modelo de ciclo de vida de projetos propostos. Ns aconselhamos que sejam considerados os pontos de avaliao descritos no modelo de ciclo de vida do desenvolvimento adotados pelo projeto para a fase de execuo. A aplicao do modelo PDCA Plan Do Check Act [Campos1992] em todas as fases do modelo de ciclo de vida tambm pode ser considerada. O ciclo PDCA de controle (Figura 4.2) objetiva a prtica do controle de processos e pode ser utilizado para manter e melhorar as diretrizes de controle de um modelo de processo. O estabelecimento de metas para cada fase importante para que o processo esteja em constante melhoria. Os itens de controle podem considerar faixas de valores padro como, por exemplo: qualidade-padro, custo-padro, prazo-padro, quantidade-padro, entre outros.
A (Action)
Atuar corretivamente
Definir as metas
P (Plan)
Definir os mtodos que permitiro atingir as metas propostas Educar e treinar Executar a tarefa (coletar dados)
Verificar os resultados da tarefa executada
C (Check)
D (DO)
FIGURA 4.2 Ciclo PDCA de controle de processos A ISO15504 [ISO15504:1-9:1998] e o CMM/CMMI [Paulk1993] [CMMI:2000] definem tambm indicadores de desempenho do processo que podem ser considerados para realizao de avaliaes para o modelo de ciclo de vida dos
41
projetos. O uso de checklist para cada ponto de avaliao definido tambm bastante til. 4.2 STAKEHOLDERS
O PMBOK [PMBOK2000] define stakeholders como sendo os indivduos ou as organizaes que esto ativamente envolvidos em um projeto. Ns estabelecemos, para efeito de simplificao, um conjunto mnimo de elementos para a empresa que podero estar envolvidos em um projeto. Estes elementos e suas funes esto apresentados a seguir: diretor responsvel por estipular as metas e diretrizes da empresa; gerente comercial responsvel por manter a interface entre a empresa e o cliente. deve estar apto a perceber demandas de mercado e a estabelecer parcerias para construo de solues mais completas para clientes. realiza tambm renegociaes de prazos e preos de projetos em execuo; gerente de tecnologia responsvel por pesquisar e estabelecer as tendncias tecnolgicas futuras da empresa. d apoio ao desenvolvimento dos produtos/servios e dissemina o conhecimento tcnico da empresa; gerente de projetos responsvel pelo gerenciamento e acompanhamento de todos os projetos de software da empresa ou de uma rea especfica. faz alocao e planejamento dos recursos da empresa como um todo ou da rea de sua responsabilidade. revisa o planejamento feito pelo lder de projeto e acompanha o uso adequado de metodologias e padres da empresa; gerente de processo e qualidade estabelece metas, juntamente com a diretoria, visando melhoria do processo de software e qualidade dos produtos/servios gerados pela empresa. encarregado pela padronizao e em auxiliar a gerncia de projetos no acompanhamento dos projetos da empresa; lder de projeto responsvel por planejar e gerenciar a execuo de um projeto especfico; tcnico neste grupo se encontra os desenvolvedores de forma geral, tais como: engenheiros de software, administradores de sistemas de workflow, analistas de sistemas, administradores da infra-estrutura, analistas de negcio, arquitetos de dados, administradores de banco de dados, web designers, entre outros; cliente organizao ou setor da empresa que solicita a execuo de um servio e/ou produto de software; empresa sub-contratada outra empresa a quem pode ser delegada a execuo de algumas atividades do projeto de software.
42
A Figura 4.3 apresenta uma proposta de organograma para uma empresa de software, representando uma hierarquia entre os stakeholders.
DIRETOR Cliente
Gerente Comercial Gerente de Tecnologia Gerente de Processo e Qualidade

Empresa Subcontratada
Gerente Projetos
Lder da Equipe 1
Lder da Equipe 2
Lder da Equipe n
Tcnicos
Tcnicos
Tcnicos
FIGURA 4.3 Organograma sugerido 4.3 ARTEFATOS
Artefato pode ser definido como um conjunto de informaes que produzido, modificado ou usado por um processo. Ns estabelecemos um conjunto mnimo de artefatos considerado crticos para o gerenciamento de projetos de software de uma empresa. Estes artefatos so: documentos de requisitos, propostas tcnicas, propostas comerciais, relatrios de teste, atas de reunio, relatrios de visitas tcnicas, planos de projeto, ordens de servio e relatrios de aceite. A Figura 4.4 apresenta estes artefatos e a influncia existente entre eles.
43
FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto Proposta Tcnica Documento Requisitos
Proposta Comercial
Relatrio Visita Tcnica Plano de Projeto
Relatrio de Aceite
Ordem de Servio
Relatrio de Teste
Ata de Reunio
Os pargrafos seguintes descrevem os artefatos, suas caractersticas principais e os responsveis por sua confeco. Ressaltamos que, o ProGer est focado mais em artefatos de gerenciamento do que em artefatos de engenharia. A Tabela 4.1 mostra os artefatos que podem ser gerados nas respectivas fases do modelo de ciclo de vida dos projetos descritos na seo 4.1. TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos projetos
Fase Prospeco Proposta Execuo Garantia Encerramento Artefatos Documentos de requisitos e atas de reunio. Documentos de requisitos, propostas comerciais, propostas tcnicas, atas de reunio. Documentos de requisitos, relatrio de teste, relatrios de aceite, planos de projeto, ordens de servio e relatrios de visitas tcnicas. Relatrios de teste, atas de reunies, ordens de servio e relatrios de visita tcnica. Atas de reunio.
Ns recomendamos que as instncias dos artefatos sejam armazenadas em uma rea comum, na pasta de seus respectivos projetos. Estabelecemos um padro para nomeao dos artefatos visando facilitar o acesso aos documentos. A Tabela 4.2 mostra este padro. TABELA 4.2 Sugesto de padro para nomeao dos artefatos
Artefato Documentos Padro para Nomeao Exemplo DocumentoRequisitos + _ + Cdigo_Projeto + _+ DocumentoRequisitos_DVX121-
44 de Requisitos Propostas Tcnica Proposta Comercial Planos de Projeto Relatrio de Teste Atas de Reunio Relatrios de Visita Tcnica Relatrios de Aceite Ordens de Servio Nmero_Verso
EDITORA UFLA / FAEPE Gerncia de Projetos de Software 01_01 PropostaTcnica_DVX121-01_0 1 PropostaComercial_DVX121-01 _01 PlanoProjeto_DVX121-01_01 RelatorioTeste_DVX121-01_200 1-01-01_01 AtaReunio_DVX121-01_200101-01_01 RelatrioTcnico_DVX121-01_2 001-01-01_01 Aceite_DVX121-01_01_01 Ordem_DVX121-01_01
PropostaTcnica + _ + Cdigo_Projeto + _+ Nmero_Verso PropostaComercial + _ + Cdigo_Projeto + _+ Nmero_Verso PlanoProjeto + _ + Cdigo_Projeto + _+ Nmero_Verso RelatorioTeste + _ + Cdigo_Projeto + _+ Data (ano-mes-dia) + _ + [Nmero_Sequencial] AtaReuinio + _ + Cdigo_Projeto + _+ Data (ano-mes-dia) + _ + [Nmero_Sequencial] RelatrioTcnico + _ + Cdigo_Projeto + Data (ano-mes-dia) + _ + [Nmero_Sequencial] Aceite + _ + Cdigo_Projeto + _+ Nmero_Aceite + _ + [Nmero_Verso] Ordem+ Cdigo_Projeto + _+ NmeroOrdem
4.3.1 Documento de requisitos Um requisito descreve uma condio ou aptido que um produto de software ou servio deve possuir para satisfazer um contrato ou uma requisio de um cliente da empresa. O documento de requisitos registra todos os requisitos funcionais e nofuncionais deste produto ou servio. Este artefato pode possuir diversas verses com nveis de refinamento diferenciados e deve ser descrito sempre em uma linguagem que pode ser entendida tanto por engenheiros de software quanto pelo cliente. A Figura 4.5 apresenta uma sugesto de contedo para este artefato. O apndice A deste mdulo apresenta um template para a confeco de um documento de requisitos. O documento de requisitos pode ser confeccionado em projetos que se encontram em todas as fases, com exceo da fase de encerramento. O mais comum sua confeco nas fases de prospeco e proposta, com o refinamento sendo realizado na fase de execuo. Este artefato pode ser feito por gerentes de projeto, gerentes comerciais, lderes de projeto e tcnicos.
45
Contedo do Documento de Requisitos
46

Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE....................................................................................2
Parceria..........................................................................................................145 Reitor ............................................................................................................145 Vice-Reitor.....................................................................................................145 Diretor da Editora...........................................................................................145 Pr-Reitor de Ps-Graduao.......................................................................145 Pr-Reitor Adjunto de Ps-Graduao Lato Sensu....................................145 Coordenao do curso..................................................................................145 Presidente do Conselho Deliberativo da FAEPE .........................................145 Editorao .....................................................................................................145 Impresso......................................................................................................145 Nenhuma parte desta publicao pode ser reproduzida, 145 Introduo 7 1.1 Projeto e a Gerncia de Projetos..........................................................................9 1.2 Motivao e Relevncia da Gerncia de Projetos..............................................10 1.3 As Dificuldades do Gerenciamento de Projetos de Software.............................11 1.4 Estrutura do Mdulo............................................................................................12 Modelos, Padres e Normas e a Gerncia de PRojetos 14 2.1 Processos de Gerenciamento da ISO/IEC15504................................................14 2.2 PMBOK................................................................................................................18 2.2.1 Gerncia de integrao de projetos........................................................19 2.2.2 Gerncia de escopo de projetos..............................................................20 2.2.3 Gerncia de tempo de projetos...............................................................21 2.2.4 Gerncia de custo de projetos.................................................................21 2.2.5 Gerncia da qualidade de projetos.........................................................22 2.2.6 Gerncia de recursos humanos de projetos...........................................22 2.2.7 Gerncia de comunicao de projetos....................................................22 2.2.8 Gerncia de risco de projetos..................................................................23 2.2.9 Gerncia de aquisio de projetos..........................................................23 2.3 Modelagem do Sistema de Processos dE Empresa de Software......................24 2.4 Elementos essenciais para criar um processo de gerncia de projetos.............25 2.5 Consideraes.....................................................................................................27 Poltica Organizacional e Padres ADotados para A definio do ProGer 30 3.1 pOLTICA oRGANIZACIONAL Considerada para o ProGer..............................30 3.1.1 Caracterizao da empresa....................................................................30 3.1.2 Metas pretendidas com a gerncia de projetos......................................32 3.2 Modelos, NOrmas e Padres Utilizados para a Definiao do ProGer................32 ProGER: Processo de Gerncia de Projetos de Software 36 4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................36 4.1.1 Controle e avaliao................................................................................39 4.2 Stakeholders .......................................................................................................41 4.3 Artefatos .............................................................................................................42 4.3.1 Documento de requisitos.........................................................................44 4.3.2 Proposta tcnica......................................................................................48 4.3.3 Proposta Comercial ................................................................................50
47
FIGURA 4.5 Sugesto de contedo para um documento de requisitos
48
4.3.2 Proposta tcnica Uma proposta tcnica apresenta uma proposio de prestao de servios para um determinado cliente. Serve como instrumento para o acompanhamento do servio prestado ou a confeco de um produto. Este artefato pode ser confeccionado por qualquer elemento da empresa, dependendo da habilidade e dos conhecimentos que este possui no escopo que est sendo abordado. Porm, sempre deve ser revisada pelo gerente de processo e qualidade e/ou gerente de projeto. O documento de requisitos pode ser especificado dentro da proposta tcnica ou estar como um anexo desta. A Figura 4.6 apresenta uma sugesto de contedo para uma proposta tcnica. O apndice A deste mdulo apresenta um template para a confeco de uma proposta tcnica. Contedo da Proposta Tcnica
49
50
FIGURA 4.6 Sugesto de contedo para uma proposta tcnica 4.3.3 Proposta Comercial Este artefato apresenta uma proposta comercial de prestao de servios para um determinado cliente e dever servir como o instrumento legal para o acompanhamento do servio prestado. Os termos aqui estabelecidos foram definidos a partir das informaes constantes na proposta tcnica quando j conhecida e aceita pelas partes envolvidas. Deve contemplar acordos referentes a preo, pagamento, garantia e multas. A confeco de uma proposta comercial de responsabilidade dos gerentes comerciais, porm deve ser aprovada pelo diretor. A Figura 4.7 sugere um contedo para uma proposta comercial. Um framework para construo de uma proposta comercial pode ser visto no Apndice A. Contedo da Proposta Comercial
51
52
FIGURA 4.7 Contedo para uma proposta comercial 4.3.4 Plano de Projeto Um plano de projeto um documento formal e aprovado que utilizado para gerenciar a execuo de um projeto [PMBOK2000]. Um plano de projeto delimita o escopo da execuo do projeto levando em conta as condicionantes (opes de deciso) escolhidas pelo cliente e anteriormente aprovadas na proposta tcnica e comercial. A estrutura de diviso do trabalho (WBS Work Breadkdown Structure ou EAP Estrutura Analtica do Projeto) o elemento central deste artefato, ou seja, a diviso do trabalho total do projeto em etapas e atividades independentes. Alm da WBS, este artefato tambm deve apresentar os padres e tcnicas adotadas, a metodologia e o modelo de ciclo de vida do desenvolvimento, os artefatos que sero utilizados e gerados, as ferramentas necessrias, o cronograma de atividades com os recursos alocados, e os critrios para concluso das atividades e etapas do projeto. O plano de projeto serve de guia para o lder de projeto acompanhar o andamento dos trabalhos e so confeccionados por lderes de projeto com aprovao do gerente de projeto e/ou gerente de processo e qualidade. A Figura 4.8 apresenta uma sugesto de contedo para um plano de projeto. Um modelo de plano de projeto pode ser visto no Apndice A.
53
Contedo do Plano de Projeto
54
55
FIGURA 4.8 Sugesto de contedo para um plano de projeto 4.3.5 Relatrio de teste Um relatrio de teste tem por finalidade o registro dos testes realizados em conjunto com os clientes (validao dos requisitos do projeto). Serve de documento base para a especificao de novos requisitos, e anlise e previso para a realizao de alteraes no produto ou servio de software. Deve possuir a concordncia dos usurios que esto envolvidos no processo de teste. importante durante a confeco deste artefato que seja feita uma referncia aos requisitos que esto sendo testados. Este artefato confeccionado por tcnicos e/ou lderes de projeto e pode ser utilizado para validar um nico ou um agrupamento de requisitos ao mesmo tempo. A Figura 4.9 apresenta um modelo para relatrio de casos de teste.
RELATRIO DE TESTE PROJETO <NOME DO PROJETO> CLIENTE <NOME DO CLIENTE> CONTRATO: <IDENTIFICADOR DO CONTRATO>
Nome do Projeto Data do Teste Repetio deste teste
[ ]1o [ ]2o [ ]3o [ ]4o [ ]5o [ ]6o [ ]7o [ ]8o [ ]9o [ ]10o [ ]11o [ ]12o
Relato do Teste e Observaes
Empresa Nome Assinatura
<Empresa>
<Cliente>
<Cliente>
FIGURA 4.9 Modelo de relatrio de teste 4.3.6 Ata de reunio
56
As atas de reunio devem registrar todas as reunies internas e externas da empresa descrevendo os tpicos discutidos e as metas estabelecidas. As atas de reunio podem ser confeccionadas por qualquer pessoa da empresa e devem conter a rubrica e aceite de todos os participantes da reunio. A Figura 4.10 apresenta um modelo para este artefato. ATA DE REUNIO
PROJETO <NOME DO PROJETO> CLIENTE <NOME DO CLIENTE> CONTRATO: <IDENTIFICADOR DO CONTRATO> Redator: <nome do redator da ata>Data/Hora Incio: <hora incio>Local: <local onde foi realizada a reunio>Data/Hora Fim: <hora fim>
1. OBJETIVO <objetivo da reunio> 2. PARTICIPANTES <relacionar nomes, funes dos participantes> 3.TPICOS DISCUTIDOS/DEFINIES <descrio do tpico> <detalhamento da definio> 4. PRXIMAS AES <detalhar a ao> Responsvel: <nome do responsvel > 5. PRXIMA REUNIO <data da prxima reunio, se for o caso> 6. OBSERVAO
Rubricas
Esta ata foi redigida por <Nome Redator/e-mail/fone>. Qualquer dvida ou discordncia, favor entrar em contato com o redator.
FIGURA 4.10 Modelo de ata de reunio 4.3.7 Relatrio de visitas tcnicas Os relatrios de visitas tcnicas tm por objetivo registrar uma visita ao cliente, solicitada para resolver um determinado problema ou para elicitar algum procedimento novo. Estes relatrios geralmente so confeccionados por tcnicos e lderes de projeto. A realizao da manuteno que envolva uma visita no cliente registrada por este artefato. A Figura 4.11 apresenta um modelo de relatrio de visita tcnica.
57
RELATRIO VISITA TCNICA

Nome do Projeto: Nome do Cliente: Identificador do Contrato: Solicitante: Local: Data Solicitao: Data Entrega Servio:
Problema / Requisio
Soluo
Observao
Empresa
Nome Assinatura
<Empresa>
<Cliente>
<Cliente>
FIGURA 4.11 Modelo de relatrio de visita tcnica 4.3.8 Relatrio de aceite Um relatrio de aceite tem por finalidade obter o aceite do cliente e avaliar o quo satisfeito ele ficou com o produto ou servio, e estabelecer metas para a resoluo dos problemas encontrados. Ns definimos dois tipos de relatrios de aceite: parcial e final. A Figura 4.12 apresenta um modelo para este artefato. O relatrio de aceite parcial estabelece a finalizao de uma etapa do projeto. Esta etapa pode ser prevista pela ocorrncia de um milestone ou mesmo pelo estabelecimento de entregas parciais do servio ou produto. Um exemplo pode ser o aceite do documento de requisitos revisado e detalhado. O relatrio de aceite final objetiva delimitar o evento que estabelece que o projeto entra na garantia.
58
FIGURA 4.12
Modelo de relatrio de aceite
Os relatrios de aceite utilizam o documento de requisitos como base e registram a satisfao do cliente, a estratgia para resoluo dos problemas RELATRIO DE ACEITE (FINAL/PARCIAL)
Projeto: <Nome do Projeto> Cliente: <Nome Cliente> Contrato: <Nmero Contrato> Aceitao: <Nmero > Data: <Data da Aceite> Responsvel: <Lder ou gerente de projeto, responsvel pelo aceite> Revisor(es): <clientes/usurios envolvidos no aceite>
I . REQUISITOS
REQUISITO FUNCIONAL <cdigo do requisito> ... ... REQUISITO NO FUNCIONAL <cdigo do requisito> ... ... DESCRIO <descrio do requisito> AVALIAO <OK, no conforme, conforme com restries>
DESCRIO <descrio do requisito>
AVALIAO < OK, no conforme, conforme com restries>
II . PRODUTOS ENTREGUES
PRODUTO <nome do produto> ... ... OBSERVAO <descrio da observao> AVALIAO < OK, no conforme, conforme com restries>
III . NO-CONFORMIDADES
<Nesta seo devem ser relacionados os desvios identificados e "como e quando" sero tratados.> ITEM RESPONSVEL AES E PRAZOS <descrio do item a ser <nome do responsvel> < como ser solucionado, data> tratado> ... ...
IV . SATISFAO DO CLIENTE COM RELAO AO SERVIO

ITEM Qualidade do atendimento Qualidade dos produtos entregues ... OBSERVA O < observao> AVALIAO < excepcional ,bom, razovel,insuficiente, pssimo>
V . CONCLUSO Servio Considerado Conforme Servio Considerado Conforme com Restrio Servio Considerado No-Conforme VI . OBSERVAO:
apontados pelo cliente e estabelecimento de novas metas para correo de noconformidades. Um relatrio de aceite pode ser confeccionado por um lder de projeto e/ou gerente de projeto. O apndice A apresenta um template para este artefato.
59
4.3.9 Ordem de Servio Uma ordem de servio registra uma requisio formal de um cliente para a realizao de um servio em projetos que esto em execuo ou j foram concludos. A ordem de servio preenchida pelo cliente e entregue ao lder do projeto. A liberao do servio solicitado necessita do aval do gerente de projeto ou gerente de processo e qualidade para que possa ser realizado. A Figura 4.13 apresenta um modelo para este artefato.
ORDEM DE SERVIO
Nome do Projeto:
Nome do Cliente: Identificador do Contrato:

Solicitante: Local: Data Solicitao: Data Entrega Servio:
Solicitao
Custo Associado
Observao
Empresa
Nome Assinatura
<Empresa>
<Cliente>
<Cliente>
FIGURA 4.13 Modelo de uma ordem de servio
4.4
FLUXOS DE TRABALHO
Os fluxos de trabalho (workflows) representam uma seqncia de atividades que so executadas em um negcio para produzir um resultado de valor para algum ator do negcio. De forma mais especfica, um fluxo de trabalho define as atividades que
60
devero ser realizadas, a interconexo entre estas atividades, os atores envolvidos e os produtos (artefatos, produtos de manufatura, comunicao, etc.) que sero gerados para satisfazer uma necessidade do negcio. A ordem da execuo de um fluxo de trabalho pode ser serial, paralela e/ou condicional. Os fluxos de trabalho podem ser descritos informalmente ou formalmente. Fluxos de trabalho formais so descritos atravs de linguagens apropriadas, as WDLs (Workflow Description Languages). Algumas destas linguagens so derivadas de modelos conceituais conhecidos na engenharia de software como statecharts [Kappel1995]. Outras, todavia, usam suas prprias estruturas conceituais como em [Casati1995] e [Rouiller1998]. Ns optamos por descrever os fluxos utilizando flowchart descrito em [Kerzner2001], por ser mais simples e permitir que sejam declarados tambm os executores de cada atividade. A Figura 4.14 apresenta as primitivas que o flowchart utiliza para descrever os fluxos de trabalho.
Elipses mostram materiais, informaes ou aes (entradas) que iniciam o fluxo ou para mostrar o resultado do trmino (sada) do fluxo Um retngulo ou caixa usado para mostrar uma tarefa ou atividade que deve ser executada no fluxo Smbolo que mostra pontos no fluxo onde uma questo est sendo realizada ou uma deciso requerida
Um crculo com uma letra ou um nmero identifica uma quebra no fluxo que continuada na mesma pgina ou em outra pgina Setas mostram a direo do fluxo
FIGURA 4.14 Primitivas do flowchart No ProGer estabelecemos trs fluxos de trabalho para uma empresa de pequeno ou mdio porte: fluxo de captao de projetos, fluxo de execuo de projetos e fluxo avaliao de projetos. Estes fluxos especificam os procedimentos que so utilizados ao longo do modelo de ciclo de vida dos projetos apresentado na seo 4.1. O Apndice B apresenta em detalhes os fluxos do ProGer. A seguir faremos uma apresentao sucinta destes fluxos. 4.4.1 Fluxo de captao de projetos O fluxo de captao de projetos define os procedimentos e artefatos que devem ser gerados pela empresa quando ocorre a identificao de uma demanda ou
61
solicitao de um servio ou produto pelo cliente. Este fluxo termina quando uma proposta comercial entregue ao cliente ou um produto, servio ou prottipo de uma demanda que foi visualizada finalizado. Cancelamentos podem ocorrer por parte do cliente ou da empresa. Este fluxo de trabalho utilizado nas fases de prospeco e proposta do modelo de ciclo de vida para projetos de software. A Figura 4.15 apresenta um resumo do fluxo de captao de projetos. O fluxo completo est definido no Apndice B deste mdulo.
Incio Cliente solicita servio ou uma devmanda visualizada
Levantamento de requisitos
Confeco do documento de requisitos
Confeco de plano de projeto S
Construo de prottipo? N Confeco e aprovao de proposta tcnica Confeco e aprovao de proposta comercial Proposta comercial entregue ao cliente
Execuo das atividades do plano de projeto
Trmino
FIGURA 4.15 Resumo do fluxo de captao de projetos A confeco de propostas tcnicas, propostas comerciais e planos de projeto necessitam de estimativas de tempo e custo, necessrias para a realizao do escopo proposto no projeto. Diversas tcnicas de estimativas existem com o intuito de prever tamanho, esforo, prazo e custo para produtos e servios de software, tais como [Trindade2000] [Braga1996] e [Boehm1981]. Muitas destas tcnicas requerem uma grande variedade de fatores de entrada, incluindo dados histricos, medidas de complexidade de sistemas, anlise de equipes de desenvolvimento, algumas restries de projeto e estimativas do volume de cdigo (o tamanho do projeto).
62
Porm, para que as tcnicas sejam efetivas a empresa deve encontrar as condies apropriadas ao seu negcio [Sanches2001]. As empresas de pequeno porte possuem de forma geral algumas limitaes que devem ser consideradas para a escolha da tcnica a ser utilizada nas estimativas de seus projetos de software, entre elas podem citar: recursos de pessoal limitado, alto rodzio de pessoal, imaturidade metodolgica, projetos executados sem planejamento detalhado, requisitos realizados geralmente por apenas um elemento da empresa, plano de risco e plano de contingncia no considerados e processo ad-hoc. O trabalho de Sanches [Sanches2001] traz uma reviso bibliogrfica dos mtodos e tcnicas utilizadas na fase de elaborao de estimativas e nas demais fases do processo de planejamento, bem como um levantamento preliminar das ferramentas disponveis para apoio s tarefas. Porm tambm conclui que, os mtodos para as estimativas, planejamento e controle das atividades devem ser simples, rpidos, eficazes e apresentados em uma linguagem mais aderente aos negcios empresariais. Ns tambm acreditamos que as empresas de pequeno porte devem utilizar tcnicas simples para estimar produtos e servios de software, porm estas tcnicas devem estar formalizadas e entendidas pelos elementos da empresa envolvidos no processo. Uma tcnica que pode ser utilizada para estimar est focada no conhecimento e capacidade de estimar das pessoas. Desta forma, est apto a estimar qualquer pessoa da empresa, dando prioridade quelas que possurem mais experincia na tecnologia que ser empregada, maiores conhecimentos do escopo do produto e/ou servio, e conhecimentos da organizao que solicitou a execuo do projeto (cliente). Sugere-se que esta estimativa seja realizada baseada nos requisitos que o projeto deve satisfazer. Para cada requisito do produto, ou servio detalhado no documento de requisitos, uma quantidade de esforo em horas deve ser estimada. Esta quantidade de horas deve considerar de preferncia sempre um profissional de nvel mdio. A Tabela 4.3, confeccionada atravs da observao de realizamos em projetos em algumas empresas de pequeno porte, apresenta um exemplo de como os nveis de profissionais podem ser considerados.
TABELA 4.3 Sugesto de categorizao de nveis de profissionais para uma empresa de pequeno porte
Projeto: Profissional Nvel do Roteamento de Caminhes Categoria de Profissionais Requisito: [RF001] Cadastramento de Rotas dos e consultores 1 Gerentes especializados Caminhes Dresser na minerao de Tamandu 2 Gerentes e tcnicos masters Tipo de atividade: Engenharia de software 3 Lderes de projetos e tcnicos seniores Complexidade :03 4 Prioridade: essencial Tcnicos juniores Horas previstas para realizao:trainees e estagirios 5 Tcnicos 24 Nvel de profissional considerado: 3
63
FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto A previso em horas determina o esforo que ser despendido para a execuo do requisito no projeto. Quando da confeco do plano de projeto, por exemplo, pode-se fazer uma estimativa mais precisa do tempo real que ser gasto estabelecendo para cada requisito a ser realizado um profissional especfico ou nveis de profissionais e quantidade necessria de profissionais. A estimativa de custo monetrio para o projeto pode ser realizada baseando-se na quantidade de horas previstas para a realizao de cada requisito do projeto e no custo da hora do profissional considerado na estimativa. A estimativa de prazo do projeto feita atravs da distribuio da disponibilidade dos recursos humanos que executaro as atividades do projeto. A Tabela 4.4 trs um resumo de mtricas que podem ser utilizadas no fluxo de captao de projetos de software. Maiores detalhes e pontos de medio podem ser vistos no Apndice B.
TABELA 4.4 Mtricas sugeridas para o fluxo de captao de projetos Mtricas Sugeridas no Fluxo de Captao de Projetos T1 = Tempo de atendimento solicitao do cliente; T2= Tempo gasto para a confeco de uma proposta tcnica/comercial T3= Tempo gasto para a avaliao de uma demanda observada T4= Tempo estimado para a realizao do prottipo T5= Tempo gasto para a construo de um prottipo T6= Tempo gasto para correo das no-conformidades do prottipo T7= Tempo gasto para a validao do prottipo HE = Horas estimadas para a realizao de um requisito de um de projeto THE (Total de horas estimadas para o projeto) = Somatrio de todas as HE V = Valor do salrio ms do profissional VH(Valor hora do profissional) = V / 170 XE (percentual do esforo estimado para o requisito no projeto) = HE / THE * 100 CE (custo estimado para o requisito) = HE * VH TCE (total do custo estimado para o projeto) = somatrio de todos CE do projeto
64
4.4.2 Fluxo de execuo de projetos O fluxo de execuo de projetos se inicia aps a aprovao de uma proposta comercial ou liberao da diretoria para a execuo de um projeto interno da empresa. O trmino deste fluxo se d quando todo o escopo do projeto foi realizado. Excees deste fluxo incluem: (1) a alterao do documento de requisitos aps seu detalhamento, (2) cancelamento do projeto por parte da empresa ou do cliente e (3) o cliente no deu um aceite satisfatrio implicando na necessidade de um novo plano de projeto. Este fluxo de trabalho ocorre na fase de execuo do modelo de ciclo de vida para projetos de software. A Figura 4.17 apresenta um resumo do fluxo de execuo de projetos. O fluxo completo est definido no Apndice B deste mdulo.
65
Incio
Anlise da proposta tcnica/comercial aprovada
Confeco e aprovao do plano de projeto
Execuo das atividades do plano de projeto
Problemas/ novos requisitos? N Obteno do aceite do projeto
Determinao da estratgia para resoluo dos problemas
Realizao das alteraes no plano de projeto
necessrio ajustes ? N Produto/Servio entregue ao cliente
Planejamento dos ajustes
Realizao das atividades de ajuste
Trmino
FIGURA 4.17 Resumo do fluxo de execuo de projeto Aps a anlise da proposta tcnica e comercial, inicia-se no fluxo de execuo de projetos a elaborao de um plano de projeto, que define a estrutura de diviso total do trabalho do projeto em etapas e atividades independentes. Outros elementos tambm so definidos antes de efetivamente iniciar os trabalhos do projeto, tais como: as tcnicas, metodologias, ferramentas e o modelo de ciclo de vida de desenvolvimento que sero adotados; artefatos que sero utilizados e gerados; riscos; cronograma de atividades; e critrios para concluso das atividades e etapas do projeto. O plano de projeto serve de guia para o lder de projeto acompanhar o andamento dos trabalhos e delimita o escopo da execuo do projeto, levando em conta as condicionantes escolhidas pelo cliente e anteriormente aprovadas na proposta tcnica e comercial.
66
Uma atividade a ser realizada em um projeto determinada por um requisito funcional ou no-funcional a ser cumprido. Uma tarefa uma ocorrncia da execuo desta atividade. Sempre que uma tarefa for executada, o executor deve estimar o percentual de realizao do requisito. Uma classe de tipo de atividade deve sempre ser associada ao requisito durante a confeco do plano de projeto, como por exemplo: engenharia de software, capacitao pessoal e coordenao. Ns propomos que quando uma tarefa for executada, o executor estabelea que tipo de atividade realizou. No caso de engenharia de software, um tipo de atividade poderia ser: levantamento de requisitos, anlise, projeto, implementao e teste. Desta forma, o apontamento de uma tarefa para uma atividade (requisito) de um projeto pode ser feito como apresentado na Figura 4.18. FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto O apontamento (registros) de todas as horas gastas nos requisitos do projeto, e
Projeto: Roteamento de Caminhes Requisito: [RF001] Cadastramento de Rotas dos Caminhes Dresser na minerao de Tamandu Tipo de atividade: Engenharia de software Subclasse da atividade : Projeto Data da execuo da atividade: 12/12/2001 Total de horas gastas: 10 horas Percentual realizado do requisito: 10% Problemas encontrados: ok Observaes: xxx xxxx xxxx
suas respectivas taxas de realizao so utilizados para obteno de algumas mtricas. A taxa de realizao, por exemplo, permite que os lderes de projeto possam visualizar o quanto o projeto evoluiu. O registro dos problemas encontrados em campo, durante o apontamento das horas, auxilia os lderes para a identificao de problemas e determinao de estratgias para a sua resoluo. Ns recomendamos, para empresas de pequeno porte, que o apontamento de horas seja feito uma vez ao dia, de preferncia no incio do expediente. O fluxo de execuo de projetos dado como finalizado aps o cliente validar e aceitar o produto ou servio de software que foi encomendado. Durante as atividades de validao, algumas no-conformidades podem ser encontradas e a empresa deve estabelecer estratgias para a realizao dos ajustes (que sero registradas nos documentos de aceite parcial e final).
67
A Tabela 4.5 apresenta algumas mtricas que podem ser utilizadas no fluxo de execuo de projetos para auxiliar o acompanhamento dos projetos e posterior anlise do desempenho do projeto. Maiores detalhes e pontos de medio podem ser vistos no Apndice B. TABELA 4.5 Mtricas sugeridas para o fluxo de execuo de projetos Mtricas Sugeridas no Fluxo de Execuo de Projetos T8 = Tempo gasto para validar um requisito T9 = Tempo gasto para realizar e validar um requisito T10 = Tempo gasto para confeccionar e aprovar o plano de projeto T11 = Tempo para obteno do aceite do produto/servio realizado T12 = Tempo gasto para correo das no-conformidades do produto/servio T13 = Tempo gasto para a validao do produto/servio h = horas gastas para execuo de uma tarefa de um requisito em um plano de projeto (apontamento dirio) x = percentual realizado do requisito (estimativa dada pelo executor ao trmino do apontamento de uma h) H = somatrio de h do requisito em um plano de projeto (apontamento total tempo gasto para realizar o requisito) TH (Total de horas gastas para a execuo de um plano de projeto) = Somatrio de todas as H TX = (percentual esforo real j gasto para a realizao do requisito do projeto) = H / TH * 100 TTX (percentual de realizao do projeto) = somatrio de todas (HE / THE * x) * 100 do projeto 4.4.3 Fluxo de avaliao de projetos O fluxo de avaliao de projetos estabelece atividades que comparam o que foi planejado para ser executado e o que foi efetivamente realizado. A Figura 4.19 apresenta um resumo do fluxo de avaliao de projetos. O fluxo completo est definido no Apndice B deste mdulo. O fluxo de avaliao de projetos permite que a empresa possa ter subsdios para tomar decises de melhoria do processo de software. A anlise do desempenho de um projeto de software depende das metas que a empresa pretende atingir com a melhoria de seu processo. Um exemplo de algumas anlises que poderiam ser feitas inclui: anlise da satisfao do cliente; desempenho das estimativas (esforo, prazo e custo); anlise das possveis causas para os problemas encontrados em campo;
68
desempenho dos recursos humanos; verificao se o trabalho realizado foi dentro do escopo inicialmente pretendido; etc.
Incio Anlise do desempenho do projeto
Identificao de melhorias para o processo
N Melhorias aprovadas? S Introduo de melhoria no processo Trmino
FIGURA 4.19 Resumo do fluxo de execuo de projetos A anlise do desempenho do projeto fornece subsdios para que melhorias possam ser identificadas para o processo de software. Um exemplo pode ser a anlise do desempenho das estimativas, que possibilita a determinao de quais recursos humanos esto mais aptos a estimar para que clientes. Isto possibilita que a empresa direcione estes elementos para a realizao de planejamentos mais realsticos de prazo e custo para o projeto. Aps identificar as possveis melhorias para o processo de software necessrio que estas melhorias sejam aprovadas antes de sua efetiva implantao na empresa. A aprovao ou no de uma melhoria para o processo depende das metas pretendidas pela organizao. A Tabela 4.6 apresenta algumas mtricas que podem ser utilizadas no fluxo de avaliao dos projetos. Maiores detalhes e pontos de medio podem ser vistos no Apndice B.
69
TABELA 4.6 Mtricas sugeridas para o fluxo de avaliao de projetos
Mtricas Sugeridas no Fluxo de Avaliao de Projetos T14 = Tempo gasto para analisar o desempenho do projeto T15 = Tempo gasto para aprovar e implantar melhorias no processo atravs da anlise do projeto T16 = Tempo gasto para planejar, executar e analisar um projeto XF (percentual de falha da estimativa do requisito) = (HE H) / HE * 100 TXF(percentual de falha da estimativa do projeto) = (THE TH) / THE * 100 TCF(percentual de falha na estimativa de custo do projeto) = (TCE TC) / TCE * 100 CEF (percentual de falha na estimativa de custo do requisito) = (CE C) / CE * 100 4.5 CONSIDERAES
Objetivamos com este captulo apresentar um exemplo de processo de gerncia de projetos que pode ser utilizado em empresas de pequeno e mdio porte. O processo aqui apresentado j foi utilizado como base para a modelagem do processo de gerncia de projetos de algumas empresas de software. O experimento mais significativo do uso deste processo est relatado em Rouiller [Rouiller2001], que descreve o acompanhamento de 81 projetos de software em uma empresa de pequeno porte. Este trabalho tambm apresenta um framework conceitual para a construo de ferramentas para apoiarem a gerncia de projetos. A Tabela 4.7 apresenta alguns procedimentos utilizados pelo ProGer que esto relacionados s reas de conhecimento definidas pelo PMBOK.
70
TABELA 4.7 Relao de alguns procedimentos do proger e as reas de conhecimento do PMBOK.

rea do Conhecimento Procedimentos do ProGer desenvolvimento e acompanhamento do plano de projeto controle da execuo do plano de projeto resoluo de problemas durante a execuo controle das verses e mudanas dos artefatos reunies peridicas para estabelecimentos de metas e de acordos uso dos fluxos de trabalho reviso dos artefatos definio do escopo do projeto atravs documento de requisitos aprovao do documento de requisitos pelo cliente reviso da especificao do documento de requisitos uso do modelo de ciclo de vida e seus artefatos associados uso dos artefatos ordem de servio e relatrio de teste para identificar novos requisitos refinamento dos requisitos antes de dar incio s atividades do projeto desenvolvimento e acompanhamento do plano de projeto definio da rastreabilidade entre os requisitos estimativa da durao das atividades dos requisitos do projeto apontamento de esforo gasto para desenvolver as atividades acompanhamento peridico da evoluo do projeto desenvolvimento e acompanhamento do plano de projeto estimativa de custos para cada atividade do projeto baseada no esforo apontamento de esforo gasto para desenvolver as atividades anlise dos dados histricos de outros projetos determinao de metas de qualidade a serem atingidas avaliao peridica do projeto, baseado nas metas de qualidade desejada avaliao da satisfao do cliente atravs do relatrio de aceite registro e anlise dos problemas na execuo dos projetos desenvolvimento e acompanhamento do plano de projeto realizao de estimativas e avaliao do desempenho dos projetos uso do ciclo PDCA controle da disponibilidade dos recursos registro das funes e responsabilidade de cada recurso uso dos fluxos de trabalho desenvolvimento e acompanhamento do plano de projeto identificao das habilidades dos recursos humanos acompanhamento e anlise do desempenho dos recursos humanos definio de milestones e reunies peridicas uso dos fluxos de trabalho reunies peridicas disseminao do conhecimento adquirido pelos recursos humanos da empresa desenvolvimento e acompanhamento do plano de projeto identificao dos riscos do projeto e estabelecimento de planos de contingncia desenvolvimento e acompanhamento do plano de projeto desenvolvimento da proposta comercial desenvolvimento do documento de requisitos
Gerncia de Integrao
Gerncia de Escopo de Projetos
Gerncia de Tempo Gerncia de Custo
Gerncia da Qualidade
Gerncia de Recursos Humanos
Gerncia de Comunicao Gerncia de Risco Gerncia de Aquisio
71
EXERCCIOS DE FIXAO:
72 1.Considerando as metas que a empresa de software pretendia alcanar com a implantao de um processo de gerncia de projetos (identificada no captulo 3 deste EDITORA UFLA / FAEPE Gerncia de Projetos de Software mdulo), quais delas voc acredita ser possvel alcanar considerando o ProGer? Identifique em que pontos do ProGer voc pode obter informaes para poder ter subsdios para efetuar a melhoria pretendida (Discuta isso no frum virtual). Lembrando que as metas pretendidas so: Melhoria da satisfao do cliente; Melhoria da qualidade dos produtos gerados; Melhoria da qualidade do processo; Melhoria do gerenciamento dos recursos humanos; Melhoria da comunicao interna e externa da empresa; Melhoria do desempenho das estimativas de esforo, custo e prazo; Melhoria do estabelecimento das metas organizacionais; Melhoria na identificao dos riscos. 2.Leia o estudo de caso da utilizao do ProGer em uma empresa de pequeno porte. Este estudo se encontra no material complementar do ambiente virtual. 3.Quais as reas de processo e as prticas bsicas do modelo CMMI que o ProGer satisfaz? (o modelo CMMI est no material complementar). Crie uma tabela com este comparativo, inclua sugestes de melhorias em artefatos e fluxos para tornar o ProGer aderente ao CMMI e apresente suas justificativas. (Pode ser utilizada a ISO15504 tambm para este exerccio). 4.Se a sua empresa desejasse implantar um processo de gerncia de projetos, de que forma voc o faria? (apenas para meditar).
5
FERRAMENTAS PARA APOIO AUTOMATIZADO AO PROGER
Alm de outros fatores, realizar o gerenciamento de projetos sem automao impossibilita a obteno de algumas mtricas e informaes gerenciais de forma mais eficiente, alm de exigir grande interveno humana. Contudo, os ambientes de gerenciamento de projetos disponveis no mercado no so especficos para software, dificultando o processo. A engenharia de processo tem se esforado no sentido de definir modelos e padres para a construo de um efetivo ambiente para o processo de software. Exemplos podem ser vistos em [Cromer1999] [Gates1997] [Machado1999] e [Maidantchik1999]. O reconhecimento da importncia dos processos e o crescimento da cultura de processo tm levado as empresas criao de ambientes de software mais eficientes, um exemplo o PSEEs - Process-Centered Software Engineering Environment. Os PSEEs integram tanto os requisitos do produto, que so o foco da engenharia de software, como os requisitos do processo, que so o foco do gerenciamento do projeto e da engenharia de processo. Apesar de reconhecer a importncia do processo de software e sua natureza dinmica, os PSEEs so ambientes ainda complexos e de difcil utilizao [Reis2000]. Muitos problemas desta abordagem ainda no esto bem resolvidos, como os mecanismos para integrao. No conceito mais amplo de PSEEs ainda inexistem ferramentas disponveis para uso efetivo pelas empresas. De forma geral so mais comuns os gerenciadores de processos, que so uma camada dos PSEEs. Todavia, estes gerenciadores desconsideram alguns elementos importantes no gerenciamento de projetos tais como: o acompanhamento do plano de projeto, o controle da execuo dos projetos, o registro dos problemas encontrados em campo, o registro das estimativas e o apontamento do esforo. O trabalho de Reis [Reis2000] faz uma retrospectiva e anlise dos PSEEs. Outra abordagem que pode ser utilizada para gerenciamento de projetos o WFMSs - Workflow Management Systems. O WFMSs so sistemas que foram
66
originalmente construdos para a indstria manufatureira e para utilizao em processos de negcio. Desta forma, no consideram a dinamicidade do processo de software. Os WFMSs tambm trabalham com o conceito da instanciao de um processo pr-definido, e cada processo de software nico. possvel tomar como base processos padres de software, mas no instanci-los como feito na manufatura. Reis [Reis2000] estabelece que existe pouca diferena entre PSEEs e produtos workflow (fluxo de trabalho), com exceo que produtos de workflow provem suporte mais direto a processos organizacionais. Ns concordamos com esta colocao. Flexibilizar e simplificar o PSEEs e WFMSs seria uma tarefa necessria para a construo de ambientes que pudessem realizar o gerenciamento dos projetos nas empresas, principalmente no que se refere obteno de mtricas para introduo de melhorias em curto prazo. As ferramentas para CSCW-Computer-supported Cooperative Work exploram o uso do computador para facilitar e garantir o trabalho colaborativo entre as pessoas. As ferramentas de CSCW podem ser utilizadas tambm com o intuito de gerenciar projetos. Contudo, uma ferramenta de CSCW frouxa e no permite o estabelecimento das responsabilidades e interdependncia entre as atividades a serem realizadas em um plano de projeto de software. Elas impossibilitam um controle mais efetivo da execuo se desconsiderarmos a confeco de um aplicativo especfico projetado sobre esta plataforma. Algumas ferramentas para gerenciamento de projetos podem ser encontradas no mercado, contudo no so especficas para software. Melo [Melo2000] apresenta alguma destas ferramentas, descrevendo suas caractersticas, funcionalidades e seus pontos fortes e fracos. Todavia estas ferramentas, em sua maioria, possibilitam somente o registro da estrutura da diviso do trabalho do projeto, tornando o acompanhamento do projeto de software precrio. A confeco dos planos est desatrelada dos processos da empresa impossibilitando manter a integridade com os elementos do processo de software. A dinamicidade da execuo de um projeto de software tambm dificulta o acompanhamento do projeto utilizando estes tipos de ferramentas, que propem a criao de novas verses do documento original. Comparar o que foi planejado com o executado uma atividade que somente pode ser realizada manualmente. Alm disso, a maioria destas ferramentas no permite o apontamento do esforo durante a execuo das atividades do projeto e o controle de acesso geralmente precrio, baseado em acesso ao documento e no atividade do projeto. O trabalho de Moura [Moura2000] relaciona algumas ferramentas que podem ser utilizadas para a gesto de projetos de software.
Ferramentas para Apoio Automatizado ao ProGer
67
Nas prximas sees apresentaremos um exemplo de conjunto de ferramentas que j foi adotada em conjunto com o ProGer, que serve como sugesto para apoiar o processo definido no captulo 4. 5.1 FERRAMENTAS UTILIZADAS EM CONJUNTO COM O PROGER
5.1.1 Microsoft Word Editor de textos, utilizado para a elaborao dos seguintes documentos: proposta tcnica; proposta comercial; documentos de requisitos; status report; matriz de rastreabilidade; pauta de reunio; cronograma de entrega; plano de iteraes; plano de gerncia de configurao; relatrios em geral.
O Word tambm utilizado em alguns outros documentos intermedirios aos citados acima, como por exemplo documentos de informaes sobre requisitos de produtos ou servios de software, avaliaes iniciais de prospeces ou propostas, motivos de cancelamento de propostas etc. O MS Word pode ser substitudo por um outro editor de texto open source como o Open Office Writer (http://www.openoffice.org/product/writer.html). 5.1.2 Microsoft Project Ferramenta proprietria da empresa Microsoft. Ferramenta utilizada para se determinar cronograma do projeto. Estipula prazos de entrega de todos os artefatos do projeto, permite alocar prioridades a atividades e projetos, delimitar a disponibilidade de recursos, definir prazos para atividades, etc. Utilizado para gerar os seguintes documentos: cronograma de entrega; wbs (estrutura analtica do projeto).
68
O MS Project pode ser substitudo por outra ferramenta open source para gerenciamento de projetos, como o dotProject (http://www.dotproject.net/). 5.1.3 Microsoft excel Ferramenta proprietria da empresa Microsoft. Planilha eletrnica utilizada para elaborao de tabelas e/ou grficos que podem ser utilizados em conjunto com o MSWord na elaborao dos seguintes documentos: documentos de requisitos; status report; matriz de rastreabilidade; time sheet; relatrio de controle dos requisitos: implementado, testado; relatrio de controle de bugs: corrigido, testado, atualizado; cronograma de entrega.
O MS Excel pode tambm ser substitudo por uma alternativa open source como o Open Office Calc (http://www.openoffice.org/product/calc.html). 5.1.4 Mantis O Mantis um issue tracker open source. Dentre os inmeros usos do Mantis podemos citar o de reportar e gerenciar mudanas. Utilizada, entre outras, para elaborao dos seguintes documentos: status report; documento de requisitos (quando se trata de requisitos adicionais, ou requisitos que ainda no esto bem definidos pelo cliente); relatrio de controle de bugs.
Mais informaes a respeito das funcionalidades da ferramenta podem ser encontradas no seguinte endereo: http://www.mantisbt.org/. Existem inmeras outras opes de issue trackers que podem ser utilizados no lugar do Mantis, exemplos: Bugzilla (http://www.bugzilla.org/) e Eventum (http://dev.mysql.com/downloads/other/eventum/).
69
5.1.5 FreeVCS Ferramenta freeware. Ferramenta de controle de verses de arquivos, importantssima para gerncia de configurao. Pode ser utilizada como ferramenta de apoio para praticamente todos os artefatos e documentos de um projeto. Mais informaes a respeito das funcionalidades da ferramenta podem ser encontradas no seguinte endereo: http://www.thensle.de/ Existem opes open source para realizar o controle de verso como o popular Subversion (http://subversion.tigris.org/). 5.1.6 Microsoft outlook Ferramenta proprietria da empresa Microsoft. Ferramenta de envio e recebimento de e-mails, utilizado como ferramenta de apoio para elaborao e refinamento dos seguintes documentos: proposta tcnica; proposta comercial; documentos de requisitos; relatrio de controle de bugs.
Mais informaes a respeito de preos, licenas e funcionalidades da ferramenta podem ser encontradas no seguinte endereo: http://www.microsoft.com/outlook/. Uma alternativa open source o Thunderbird (http://www.mozilla.com/enUS/thunderbird/). 5.1.7 Microsoft Windows Live Messenger Ferramenta utilizada para fazer reunies e vdeo conferncias, inclusive. Essa ferramenta sncrona permite que o gerente tire dvidas com um cliente que esteja fisicamente longe e a qualquer momento que o mesmo esteja conectado. Tambm pode ser utilizada como apoio elaborao e refinamento dos seguintes documentos, entre outros: proposta tcnica; proposta comercial; documentos de requisitos;
70
relatrio de controle de bugs.
Mais informaes a respeito de licenas e funcionalidades da ferramenta podem ser encontradas no seguinte endereo: http://get.live.com/messenger/overview 5.1.8 Base de acompanhamento de projetos A ferramenta, especfica para gerenciamento de projetos, intitulada Base de Acompanhamento de Projetos, foi construda tendo como base o ProjectSpace6 [Rouiller2001] e considera as particularidades do ProGer. Esta ferramenta foi construda na plataforma Lotus-Notes, que um ambiente adequado para trabalho cooperativo e que envolve muita colaborao humana. A Figura 5.1 mostra uma viso do cadastramento de projetos. A notificao ao gerente de processo e qualidade e ao diretor feita automaticamente quando um novo projeto criado. Cada projeto inicia-se em uma fase especfica, baseada no modelo de ciclo de vida de projetos descritos pelo ProGer. Para cada fase so associados os recursos que sero utilizados e quem ser o responsvel pelo projeto. A Base de Acompanhamento de Projetos permite a notificao aos executores e a convocao de reunies. Lembrando que, um projeto pode ser iniciado em qualquer fase, com exceo do encerramento. A Figura 5.2 apresenta uma viso do cadastramento da fase do projeto.
O ProjectSpace um framework conceitual que pode ser utilizado para a construo de ferramentas para gerenciamento de projetos de software e foi concebido considerando os padres da engenharia de
6
processo e do gerenciamento de projetos.
71
FIGURA 5.1 Viso do cadastramento de projetos
FIGURA 5.2 Viso do cadastramento de fases do projeto
72
Aps a criao de um projeto em uma determinada fase macro-atividades7 so criadas pelo lder de projeto. O gerente de projeto notificado da criao de todas as macro-atividades, assim como os executores. Para uma macro-atividade pode ser atribudo um ou mais executores. O lder de projeto deve fazer uma previso do esforo em tempo que ser gasto para a realizao da macro-atividade, alm de determinar a sua complexidade. A Figura 5.3 mostra uma viso do cadastramento de uma macro-atividade.
FIGURA 5.3 Viso do cadastramento de macro-atividades Posteriormente, os executores registram os tempos gastos (apontamento de horas) nas macro-atividades, relacionando o tipo de atividade realizada. O executor faz uma estimativa da realizao da macro-atividade, neste momento. Problemas encontrados em campo so notificados ao lder de projeto, neste momento. A Figura 5.4 mostra uma viso do apontamento de horas nas macro-atividades.
As macro-atividades representam os requisitos funcionais e no-funcionais do produto ou servio de software e possuem uma subclasse de atividade associada.
7
73
FIGURA 5.4 Viso do apontamento de horas nas macro-atividades Informaes gerenciais tambm podem ser obtidas atravs de relatrios solicitados pela gerncia e diretoria. A Figura 5.5 apresenta uma viso dos projetos por fase e cliente, apresentando os requisitos dos projetos e as respectivas taxas de realizao. Uma viso do esforo gasto em horas nos projetos dada pela Figura 5.6.
74
FIGURA 5.5 Viso de projetos por fase e cliente
FIGURA 5.6 Viso das horas gastas nos projetos A Figura 5.7 apresenta uma viso mostrando as horas apontadas por executor em projetos na Base de Acompanhamento de Projetos. A Figura 5.8 mostra a viso diria do trabalho do executor.
75
FIGURA 5.7 Uma viso das horas gastas por colaborador
FIGURA 5.8 Viso diria do trabalho do executor
76
EXERCCIOS DE FIXAO:
1. Voc julga importante a utilizao de ferramentas especficas de gerncia de projetos? Por que quase toda organizao de software geralmente constri uma ferramenta proprietria (como a Base de Acompanhamento de Projetos) quando inicia a automatizao do processo de gerenciamento? Compartilhe sua opinio no frum virtual. 2. Fornea sugestes de outras atividades do ProGer que poderiam ser apoiadas usando uma ferramenta que voc conhece. 3. Que ferramentas gratuitas ou open source voc conhece para apoiar a gerncia de projetos de software? Voc j as utilizou? Compartilhe seu conhecimento no frum virtual.
6
CONCLUSO
Este mdulo apresentou conceitos bsicos da gerncia de projetos de software, enfatizando sua relevncia e dificuldade de implantao nas empresas. Abordamos tambm, no captulo 2, alguns modelos para a construo de um processo para gerncia de projetos. Os captulos seguintes apresentaram um exemplo de processo de gerncia de projetos de software. A seguir realizaremos algumas consideraes. As dificuldades de se implantar um processo para gerenciamento de projetos em empresas de software esto, principalmente, na falta de cultura em qualidade que as organizaes possuem (principalmente as de pequeno e mdio porte). O alto rodzio de pessoal e o constante deslocamento de recursos humanos para suprir a demanda de um outro projeto, tambm, dificulta o bom desempenho de um processo de gerenciamento de projetos de software. Realizar o gerenciamento dos projetos sem a automao de alguns procedimentos do processo uma tarefa muito rdua, e porque no dizer, que quase inviabiliza a obteno de dados para a melhoria do processo. Infelizmente, poucas ferramentas so apropriadas ao gerenciamento de projetos de software. Apesar de sua relevncia, temos observado que o gerenciamento de projetos nas empresas de software ainda realizado geralmente de forma ad-hoc, causando inmeros prejuzos organizao, inclusive financeiros. Contudo, existe uma forte tendncia ao surgimento de novos trabalhos nesta rea. Isso pode ser observado atravs dos processos includos nos padres e normas para SPA/SPI e em estudos e publicaes realizados nos ltimos anos. Acreditamos que a comunidade de software deva, em breve, considerar mais as experincias adquiridas e apresentadas pelo PMI-Project Management Institute. Isso inclui a realizao de certificao para seus gerentes de projeto, assim como j ocorre com linguagens e tecnologia, garantindo uma melhor qualidade dos projetos que executam. Notamos tambm uma tendncia dos adquirentes de produtos e servios de software em exigirem gerentes de projetos certificados pelo PMI, para
78
terem mais garantia de que a execuo de seus projetos estar de acordo com a especificao pretendida nos contratos. Na construo de um processo para gerncia de projetos, os padres e normas para SPA/SPI se mostram eficientes, contudo, no so suficientes. O PMBOK possibilita um melhor entendimento e uma ampliao mais eficaz dos conhecimentos da rea de gerenciamento de projetos para a rea de software. Esperamos que este mdulo tenha contribudo para elucidar a relevncia do gerenciamento de projetos nas empresas de software e tambm possibilitado ao aluno mecanismos para que este possa se aprofundar no tema.
7
REFERNCIAS BIBLIOGRFICAS
[Bellouquim1999] Belouquim, A. CMM em Pequenas Organizaes: Seria Mesmo Possvel? Developers Magazine, Janeiro, 1999. [Boehm1981] Hoehm. B. Software Engineering Economics. Eglewood Cliffs, PrenticeHall Inc. 1981. [Boehm1988] Boehm, B. A Spiral Model for Software Development and Enhancement, Computer, vol. 21, n. 5, maio 1988. [Braga1996] Braga, A. Anlise de Pontos por Funo. Rio de Janeiro: Infobook, 1996. [Campos1992] Campos, V. F. TQC:Controle da Qualidade Total, Fundao Christiano Otooni, 7a. edio 1992. [Casati1995] Casati, F and Ceri, S. and Pernici, B and Pozzi, G. Conceptual Modelling of Workflows. International Conference on Object-Oriented and Entity-Relationalship OOEF95, Gold Coast, Austrlia, 1995. [CMMI:2000] CMMI Model Componentes Derived from CMMI SE/SW, Version 1.0 Technical report CMU/SEI-00-TR24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. [Cromer1999] Cromer, T. & Horch, J. From the many to the one-one companys path to standardization. IEEE, 1999. [DOD1994] Defense Science Board, Report of the Defense Science Board Task force on Acquiring Defense Software Commercially, Wahington D.C., Junho, 1994.
80
[Dorling1993] Dorling, A. Software Process Improvement Determination, Software Quality Journal, vol2, N. 4,1993.
and
Capability
[Fernandes1989] Fernandes, Aguinaldo Aragon & Kugler, J. L. C. Gerncia de Projetos de Sistemas. Rio de Janeiro, LTC, 1989. [Garg1996] Garg, P. K. Process-centered Software Engineering Environments. Published by IEEE Computer Society Press, Los Alamitos, CA 90720-1264, 1996. [Gates1997] Gates, L. P. How to Use the Software Process Framework. Special Report CMU/SEI-97-SR-009, 1997. [Gibbs1994] W. Gibbs. Software's Chronic Crisis. Scientific American Magazine, setembro, 1994. [Graham1999] Graham, I. S & Henderson-Sellers, B. & Younessi, H. The OPEN Process Specification, Addison Wesley Longman Inc. outubro, 1999. [Humphrey1989] Humphrey, W. S. Managing the Software Process, Addison Wesley Longman Inc, 1989. [ISO12207:1995] ISO/IEC 12207, Information Technology Software Life-Cycle Processes, International Standard Organization, Geneve,1995. [ISO12207:2000] International Standard Organization. ISO/IEC 12207 Amendement: Information Technology Amendement to ISO/IEC 12207, verso PDAM 3, novembro 2000. [ISO15504:1-9:1998] ISO/IEC TR 15504, Parts 1-9: Information Technology Software Process Assessment, 1998. [ISO9000-3:1997] ISO9000-3, Quality management and Quality Assurance Standards part 3: guidelines for the application of ISO 9001 to the development, supply and maintenance of software. International Standard Organization, Geneve, 1997. [Jones1996] Jones, C. Patterns of Software Systems Failure and Success. International Thomson Computer Press, Boston, Massachusetts, 1996.
Referncias Bibliogrficas
81
[Jones1999] Jones, C. Software Project Management in the 21st Century. American Programmer, Volume XI, N. 2, fevereiro 1999. [Kappel1995] Kappel, G. and Rusch-Schott, S. and Retschitzegger, W. Rule Patterns for Designing Active Object-Oriented Database Applications. Technical Report TR-07/95, Linz- Austria, 1995. [Kerzner2001] Kerzner, H. Project Management - A System Approach to Planning,Scheduling, and Controlling, 7 ed., New York, John Wiley & Sons Inc.,2001. [Kuvaja1993] Kuvaja, P. et all BOOTSTRAP: Europes assessment method, IEEE Software, vol 10, N. 3, 1993 [Kuvaja1994] Kuvaja, P. et al. Software Process Assessment & Improvement The BOOTSTRAP Approach, Blackwell, 1994. [Laitinen2000] Laitinen, M. & Fayad, M & Ward, R. Software Engineering in the Small. IEEE Software, setembro/outubro, 2000. [Lindvall2000] Lindvall, M. & Rus, I. Process Diversity in Software Development, IEEE Software, julho/agosto 2000. [Machado1999] Machado, L. F. D. C. Modelo para Definio de Processos de Software na Estao Taba, dissertao de mestrado, COPPE/UFRJ, 1999, Rio de Janeiro, RJ. [Machado2001] Machado, C. A. & Burnett, R. C. Gerncia de Projetos na Engenharia de Software em Relao as Prticas do PMBOK. XII CITS - Conferncia Internacional de Tecnologia de Software. Junho, 2001. [Maidantchik1999] Maidantchik, C. & Rocha, A R. C. & Xexeo, G. B Software Process Standardization for Distributed Working Groups. In Proceedings of the 4 th IEEE International Software Engineering Standards Symposioum, Curitiba, Paran, Brasil, maio de 1999. [MCT] http://www.mct.gov.br, acessado em dezembro de 2001.
82
[Melo2000] Melo, E. F. & Moura, H. P. WebManager: uma ferramenta para planejamento e gerenciamento de projetos de software, trabalho de graduao, Centro de Informtica, Universidade Federal de Pernambuco, agosto, 2000. [Paulk1993] Paulk, M. & Curtis, B. & Crissis, M & Weber, C. Capability Maturity Model for Software, Version 1.1, Technical report CMU/SEI-93-TR-24, Software Engineering Institute, Pittsburgh, fevereiro, 1993. [Paulk1997] Paulk, M. C & Weber, C. V & Curtis, B. & Chrissis, M. B. The Capability Maturity Model: Guidelines for Improving the Software Process. Carnegie Mellon University, Software Engineering Institute, Addison-Wesley Longman Inc, 1997. [Philippe1998] Philippe, K. The Rational Unified Process: an Introduction. AddisonWesley Object Technology Series, 1998. [PMBOK2000] A Guide to the Proiject Management Body of Knowledge, PMI-Project Management Institute, Newtown Square, Pennsylvania, USA, 2000. [PMIWBS] PMI Project http://www.pmi.org/standards/. Management Standards Program.
[Pressman1995] R. S. Pressman. Software Engineering: A Practitioner's Approach. McGraw-Hill, 3 ed., 1995. [Reis2000] Reis, C. A. L., Ambientes de Desenvolvimento de Software e seus Mecanismos de Execuo de Processos de Software, Exame de Qualificao de Doutorado, PPGC-UFRGS, 2000. [Rouiller2001] Rouiller A. C. Gerenciamento de Projetos de Software para Empresas de Pequeno Porte. Doutorado em Cincia da Computao pela UFPE. Engenharia de Software e Qualidade de Software, 2001. [Royce1998] Royce, W. Software Project Management: a unified framework. Addison Wesley Longman, 1998, USA. [Sanches2001] Sanches, R. & Jnior, W. T. Proposta de um Modelo de Processo de Planejamento de Projeto de Software para Melhoria de Gerenciamento de Projetos. XII CITS - Conferncia Internacional de Tecnologia de Software, junho, 2001.
Referncias Bibliogrficas
83
[Standish1995] The Standish Group, Chaos, www.standishgroup.com/visitor/voyahes.html, acessado em dezembro de 2001. [Trindade2000] Trindade, A. L. P Contructive Cost Model. http://metricas.tw.eng.br/htmls/cocomo-b-html, acessado em dezembro de 2001. [Vigder1994] Vigder, M. R. & Kark, A. W. Software Cost Estimation and Control. National Research Council Canada. Institute for Information Technology, 1994. http:// wwwsel.iit.nrc.ca/abstracts/NRC37116.abs, acessado em dezembro de 2001. [Walker1997] Walker, E. Managing Successful Iterative Development Projects: A Seminar on Software Best Practices, version 2.3, Rational Software Corporation, Menlo Park, California, 1997. [Wang1999] Wang, Y. & Court, I. & Ross, M. & Staples, G. & King, G. & Dorling, A. Quantitative Evaluation of the SPICE, CMM, ISO9000 and BOOTSTRAP, Transactions of IEEE, agosto, 1999. [Weber1999] Weber, K. C Qualidade e Produtividade em Software. 3 ed. So Paulo: Makron Books do Brasil Ltda, 1999.
8
APNDICE A
Neste apndice sero apresentados os seguintes artefatos do ProGer:
1. Proposta Comercial 2. Proposta Tcnica 3. Documento de Requisitos 4. Plano de Projeto 5. Relatrio de Aceite 6. Relatrio de Teste 7. Ordem de Servio 8. Funcionalidades
9
APNDICE B
Neste apndice sero apresentados os seguintes encartes, anexos ao mdulo Gerncia de Projetos de Software:
1. Fluxo de captao de projetos de produtos e servios de software;
2. Fluxo de execuo e avaliao de projetos de produtos e servios de software.

Apostila Gerencia de Projetos de Software

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Apostila Gerencia de Projetos de Software

Încărcat de

Drepturi de autor:

Formate disponibile

CURSO DE PS-GRADUAO LATO SENSU (ESPECIALIZAO) A DISTNCIA MELHORIA DE PROCESSO DE SOFTWARE LIVRE

Gerncia de Projetos de Software

Ana Cristina Rouiller

Universidade Federal de Lavras - UFLA

Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE Lavras MG

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

escopo, tempo, custo e qualidade (objetivos do projeto);

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

MOTIVAO E RELEVNCIA DA GERNCIA DE PROJETOS

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

PROCESSOS DE GERENCIAMENTO DA ISO/IEC15504

Modelos, Padres e Normas e a Gerncia de Projetos

Processos do Ciclo de Vida Categoria

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

Modelos, Padres e Normas e a Gerncia de Projetos

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

Modelos, Padres e Normas e a Gerncia de Projetos

2.2.1 Gerncia de integrao de projetos

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

FIGURA 2.3 reas do gerenciamento de projetos do PMBOK

Gerncia de Recursos Humanos

Modelos, Padres e Normas e a Gerncia de Projetos

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

Modelos, Padres e Normas e a Gerncia de Projetos

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

MODELAGEM DO SISTEMA DE PROCESSOS DE EMPRESA DE SOFTWARE

Modelagem do sistema de processo

Modelo de avaliao do processo

Modelo de melhoria do processo

Subsistema do processo organizacional

Subsistema do processo de desenvolvimento

Subsistema do processo de gerenciamento

Modelo de capacidade do processo

Mtodo de determinao da capacidade do processo

Modelo de melhoria baseado em avaliao

Modelo de melhoria baseado em Benchmark

Escala do desempenho da pratica

Escala da capacidade do processo

Escopo da capacidade do processo

Determinao da capacidade do processo

Agregao de capacidade do projeto

Agregao da capacidade da organizao

Modelos, Padres e Normas e a Gerncia de Projetos

ELEMENTOS ESSENCIAIS PARA CRIAR UM PROCESSO DE GERNCIA DE PROJETOS

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

Processo de gerenciamento de projetos de software

Ferramentas de gerenciamento de projetos de software

Esta recomendao se aplica tambm a outras reas de processo e no somente a gerncia de

Modelos, Padres e Normas e a Gerncia de Projetos

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

Modelos, Padres e Normas e a Gerncia de Projetos

Poltica Organizacional e Padres Adotados para a definio do ProGer

1993 1995 1997 1999

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

MODELOS, NORMAS E PADRES UTILIZADOS PARA A DEFINIAO DO PROGER

Poltica Organizacional e Padres Adotados para a definio do ProGer

EDITORA UFLA / FAEPE Gerncia de Projetos de Software

Comparao entre as reas de conhecimento do PMBOK, o CMM e a ISO/IEC15504

PMBOK Integrao Escopo Tempo

Risco Garantia de Qualidade

Gerncia de Risco Gerncia da Qualidade