apostila gerencia de projetos de software

101
 CURSO DE PÓS-GRADUAÇÃO “LATO SENSU” (ESPECIALIZAÇÃO) A DISTÂNCIA  MELHORIA DE PROCESSO DE SOFTWARE LIVRE Gerência de Projetos de Software Ana Cristina Rouiller Universidade Federal de Lavras - UFLA

Upload: aline-antunes-dias

Post on 18-Jul-2015

196 views

Category:

Documents


1 download

TRANSCRIPT

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 1/101

 

CURSO DE PÓS-GRADUAÇÃO“LATO SENSU” (ESPECIALIZAÇÃO) A

DISTÂNCIA MELHORIA DE PROCESSO DE SOFTWARE

LIVRE

Gerência de Projetosde Software

Ana Cristina Rouiller 

Universidade Federal de Lavras - UFLA

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 2/101

 

Fundação de Apoio ao Ensino, Pesquisa e Extensão - FAEPELavras – MG

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 3/101

 

ParceriaUniversidade Federal de Lavras - UFLAFundação de Apoio ao Ensino, Pesquisa e Extensão - FAEPE

Reitor  Antônio Nazareno Guimarães Mendes

Vice-Reitor Elias Tadeu Fialho

Diretor da EditoraMarco Antônio Rezende Alvarenga

Pró-Reitor de Pós-GraduaçãoJoel Augusto Muniz

Pró-Reitor Adjunto de Pós-Graduação “Lato Sensu”Marcelo Silva de Oliveira

Coordenação do curso Ana Cristina Rouiller Guilherme Bastos Alvarenga

Marcelo Silva de OliveiraPresidente do Conselho Deliberativo da FAEPE

Luiz Antônio LimaEditoração

Centro de Editoração Quality GroupImpressão

Gráfica Universitária/UFLA

Ficha Catalográfica Preparada pela Divisão de Processos Técnicos daBiblioteca Central da UFLA

Nenhuma parte desta publicação pode ser reproduzida,por qualquer meio, sem a prévia autorização da FAEPE.

Rouiller, Ana CristinaGerência de Projetos de Software/Ana Cristina Rouiller. –

Lavras: UFLA/FAEPE, 2008.

85 p.:il. – (Curso de Pós-graduação “LatoSensu” (Especialização) a Distância – Produção de Software (comênfase em Software Livre)

Bibliografia

1. Sistema de informação. 2. Tecnologia de informação. 3.Gerenciamento de software. 4. Software. 5. Projeto. 6. Gerência. I.Universidade Federal de Lavras. II. Fundação de Apoio ao Ensino,Pesquisa e Extensão. III. Título.

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 4/101

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 5/101

 

SUMÁRIO

Fundação de Apoio ao Ensino, Pesquisa e Extensão - FAEPE ......................................................................... ........ ...2

Parceria ..........................................................................................................145

Reitor ............................................................................................................ 145Vice-Reitor .....................................................................................................145Diretor da Editora ...........................................................................................145Pró-Reitor de Pós-Graduação .......................................................................145Pró-Reitor Adjunto de Pós-Graduação “Lato Sensu” ....................................145Coordenação do curso .................................................................................. 145Presidente do Conselho Deliberativo da FAEPE ......................................... 145Editoração .....................................................................................................145Impressão ......................................................................................................145

Nenhuma parte desta publicação pode ser reproduzida,145

Introdução 71.1 Projeto e a Gerência de Projetos..........................................................................91.2 Motivação e Relevância da Gerência de Projetos..............................................101.3 As Dificuldades do Gerenciamento de Projetos de Software.............................111.4 Estrutura do Módulo............................................................................................12

Modelos, Padrões e Normas e a Gerência de PRojetos 142.1 Processos de Gerenciamento da ISO/IEC15504................................................142.2 PMBOK................................................................................................................18

2.2.1 Gerência de integração de projetos........................................................192.2.2 Gerência de escopo de projetos..............................................................20

2.2.3 Gerência de tempo de projetos...............................................................212.2.4 Gerência de custo de projetos.................................................................212.2.5 Gerência da qualidade de projetos.........................................................222.2.6 Gerência de recursos humanos de projetos...........................................222.2.7 Gerência de comunicação de projetos....................................................222.2.8 Gerência de risco de projetos..................................................................232.2.9 Gerência de aquisição de projetos..........................................................23

2.3 Modelagem do Sistema de Processos dE Empresa de Software......................242.4 Elementos essenciais para criar um processo de gerência de projetos.............252.5 Considerações.....................................................................................................27

Política Organizacional e Padrões ADotados para A definição do ProGer 30

3.1 pOLÍTICA oRGANIZACIONAL Considerada para o ProGer..............................303.1.1 Caracterização da empresa....................................................................303.1.2 Metas pretendidas com a gerência de projetos......................................32

3.2 Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer................32ProGER: Processo de Gerência de Projetos de Software 36

4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................364.1.1 Controle e avaliação................................................................................39

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 6/101

 

4.2 Stakeholders .......................................................................................................414.3 Artefatos .............................................................................................................42

4.3.1 Documento de requisitos.........................................................................444.3.2 Proposta técnica......................................................................................484.3.3 Proposta Comercial ................................................................................504.3.4 Plano de Projeto......................................................................................524.3.5 Relatório de teste.....................................................................................55

Nome 55Assinatura 55

4.3.6 Ata de reunião.........................................................................................554.3.7 Relatório de visitas técnicas....................................................................56

RELATÓRIO VISITA TÉCNICA .......................................................................58Solicitante: 58Data Solicitação: 58Local: 58Data Entrega Serviço: 58

Problema / Requisição......................................................................................................................................... ......58

Nome 58Assinatura 58

4.3.8 Relatório de aceite...................................................................................584.3.9 Ordem de Serviço....................................................................................60

ORDEM DE SERVIÇO ....................................................................................60Solicitante: 60Data Solicitação: 60Local: 60Data Entrega Serviço: 60Nome 60Assinatura 60

4.4 Fluxos de Trabalho .............................................................................................604.4.1 Fluxo de captação de projetos................................................................614.4.2 Fluxo de execução de projetos ...............................................................654.4.3 Fluxo de avaliação de projetos................................................................69

4.5 Considerações ....................................................................................................71Ferramentas para APOIO Automatizado ao ProGer 65

5.1 Ferramentas Utilizadas em Conjunto com o ProGer..........................................675.1.1 Microsoft Word ........................................................................................675.1.2 Microsoft Project .....................................................................................675.1.3 Microsoft excel.........................................................................................68

5.1.4 Mantis......................................................................................................685.1.5 FreeVCS..................................................................................................695.1.6 Microsoft outlook......................................................................................695.1.7 Microsoft Windows Live Messenger........................................................695.1.8 Base de acompanhamento de projetos...................................................70

CONCLUSÃO 77REFERÊNCIAS BIBLIOGRÁFICAS 79APÊNDICE A 86APÊNDICE B 1

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 7/101

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 8/101

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 9/101

 

LISTA DE FIGURAS

FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento deprojeto e engenharia do produto 8

FIGURA 2.1 As dimensões do modelo de referência da ISO/IEC15504 15FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19FIGURA 2.3 Áreas do gerenciamento de projetos do PMBOK 20FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de

software 2426

FIGURA 2.5 Modelo para criação de processo de gerenciamento de projetos desoftware 26

FIGURA 3.1 Porte das empresas, segundo a força de trabalho efetiva 31FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37FIGURA 4.2 Ciclo PDCA de controle de processos 40

FIGURA 4.3 Organograma sugerido 42FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos

projetos 43TABELA 4.2 Sugestão de padrão para nomeação dos artefatos 43FIGURA 4.5 Sugestão de conteúdo para um documento de requisitos 47FIGURA 4.6 Sugestão de conteúdo para uma proposta técnica 50FIGURA 4.7 Conteúdo para uma proposta comercial 52FIGURA 4.8 Sugestão de conteúdo para um plano de projeto 55FIGURA 4.9 Modelo de relatório de teste 55FIGURA 4.10 Modelo de ata de reunião 56

FIGURA 4.11 Modelo de relatório de visita técnica 57FIGURA 4.12 Modelo de relatório de aceite 58FIGURA 4.13 Modelo de uma ordem de serviço 59FIGURA 4.14 Primitivas do flowchart 60FIGURA 4.15 Resumo do fluxo de captação de projetos 61TABELA 4.3 Sugestão de categorização de níveis de profissionais para uma

empresa de pequeno porte 62FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto

63TABELA 4.4 Métricas sugeridas para o fluxo de captação de projetos 63FIGURA 4.17 Resumo do fluxo de execução de projeto 65

FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto66TABELA 4.5 Métricas sugeridas para o fluxo de execução de projetos 67FIGURA 4.19 Resumo do fluxo de execução de projetos 68TABELA 4.6 Métricas sugeridas para o fluxo de avaliação de projetos 69TABELA 4.7 Relação de alguns procedimentos do proger e as áreas de

conhecimento do PMBOK. 70FIGURA 5.1 Visão do cadastramento de projetos 71FIGURA 5.2 Visão do cadastramento de fases do projeto 71

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 10/101

 

FIGURA 5.3 Visão do cadastramento de macro-atividades 7273

FIGURA 5.4 Visão do apontamento de horas nas macro-atividades 7374

FIGURA 5.5 Visão de projetos por fase e cliente 7474

FIGURA 5.6 Visão das horas gastas nos projetos 74FIGURA 5.7 Uma visão das horas gastas por colaborador 75

75FIGURA 5.8 Visão diária do trabalho do executor 75

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 11/101

 

LISTA DE TABELAS

FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento deprojeto e engenharia do produto 8

FIGURA 2.1 As dimensões do modelo de referência da ISO/IEC15504 15

FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19FIGURA 2.3 Áreas do gerenciamento de projetos do PMBOK 20FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de

software 2426

FIGURA 2.5 Modelo para criação de processo de gerenciamento de projetos desoftware 26

FIGURA 3.1 Porte das empresas, segundo a força de trabalho efetiva 31FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37FIGURA 4.2 Ciclo PDCA de controle de processos 40FIGURA 4.3 Organograma sugerido 42

FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dosprojetos 43

TABELA 4.2 Sugestão de padrão para nomeação dos artefatos 43FIGURA 4.5 Sugestão de conteúdo para um documento de requisitos 47FIGURA 4.6 Sugestão de conteúdo para uma proposta técnica 50FIGURA 4.7 Conteúdo para uma proposta comercial 52FIGURA 4.8 Sugestão de conteúdo para um plano de projeto 55FIGURA 4.9 Modelo de relatório de teste 55FIGURA 4.10 Modelo de ata de reunião 56FIGURA 4.11 Modelo de relatório de visita técnica 57

FIGURA 4.12 Modelo de relatório de aceite 58FIGURA 4.13 Modelo de uma ordem de serviço 59FIGURA 4.14 Primitivas do flowchart 60FIGURA 4.15 Resumo do fluxo de captação de projetos 61TABELA 4.3 Sugestão de categorização de níveis de profissionais para uma

empresa de pequeno porte 62FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto

63TABELA 4.4 Métricas sugeridas para o fluxo de captação de projetos 63FIGURA 4.17 Resumo do fluxo de execução de projeto 65FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto

66TABELA 4.5 Métricas sugeridas para o fluxo de execução de projetos 67FIGURA 4.19 Resumo do fluxo de execução de projetos 68TABELA 4.6 Métricas sugeridas para o fluxo de avaliação de projetos 69TABELA 4.7 Relação de alguns procedimentos do proger e as áreas de

conhecimento do PMBOK. 70FIGURA 5.1 Visão do cadastramento de projetos 71FIGURA 5.2 Visão do cadastramento de fases do projeto 71FIGURA 5.3 Visão do cadastramento de macro-atividades 72

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 12/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

73FIGURA 5.4 Visão do apontamento de horas nas macro-atividades 73

74FIGURA 5.5 Visão de projetos por fase e cliente 74

74FIGURA 5.6 Visão das horas gastas nos projetos 74

FIGURA 5.7 Uma visão das horas gastas por colaborador 7575

FIGURA 5.8 Visão diária do trabalho do executor 75

8

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 13/101

 

1INTRODUÇÃO

 A Engenharia de Software tem por finalidade auxiliar na construção de softwareda melhor maneira possível [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]:

• Previsão pobre – desenvolvedores não prevêem adequadamente quantotempo e esforço serão necessários para produzir um sistema de softwareque satisfaça às necessidades (requisitos) dos clientes/usuários. Sistemasde software são geralmente entregues muito tempo depois do que foraplanejado;

• Programas de baixa qualidade – programas de software não executam oque o cliente deseja, conseqüência, talvez, da pressa para se entregar oproduto. Os requisitos originais podem não ter sido, completamente,especificados ou podem apresentar contradições e isto pode ser descobertomuito tarde durante o processo de desenvolvimento;

• Alto custo para manutenção – a manutenção pode ser corretiva, quandoocorrem enganos (erros, falhas) no sistema já entregue, ou evolutiva quandonovas características são adicionadas ao sistema de software. Ambas sãocaras quando o sistema original foi construído sem uma arquitetura clara evisível;

• Duplicação de esforços – é difícil compartilhar soluções ou reusar códigos,em função das características de algumas linguagens adotadas, por falta deconfiança no código feito por outra pessoa e até mesmo pela

ausência/deficiência de documentação das rotinas e dos procedimentos jáconstruídos.

Para solucionar alguns destes problemas muitas empresas de software têmadotado metodologias de desenvolvimento de software. Todavia, os paradigmasmetodológicos para desenvolvimento de software têm sido considerados somente emtermos de “um método” de análise/projeto/implementação, isto é, um conjunto deconceitos, técnicas e notações. Esta visão elimina os aspectos tecnológicos,

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 14/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

contextuais e organizacionais que potencialmente existem dentro de um processo desoftware.

De forma geral, podemos dividir as funções de uma empresa de software emtrês grupos principais [Garg1996]:

• definir, analisar, simular, medir e melhorar os processos da organização;• construir o produto de software;

• medir, controlar, modificar e gerenciar os projetos de software.

Estes três grupos são abordados, respectivamente, pela engenharia doprocesso, pela engenharia do produto e pelo gerenciamento de projeto.  Orelacionamento entre estes grupos é mostrado na Figura 1.1 [Garg1996].

 A  engenharia do produto é encarregada do desenvolvimento e manutençãodos produtos e serviços de software. A principal figura da engenharia do produto é a

metodologia de desenvolvimento, que engloba uma linguagem de representação, ummodelo de ciclo de vida e um conjunto de técnicas. Os ambientes tradicionais dedesenvolvimento de software têm se preocupado essencialmente com a engenhariado produto, assumindo um processo implícito e tendo como foco o produto. Todavia,a engenharia do produto por si só é insuficiente para suprir as necessidades de umaorganização que desenvolve software e torná-la mais produtiva e adequada àsexigências do mercado.

Engenharia do

processo

Gerenciamento de

projeto

Engenharia do

produto

Modelo do

 processo

Requisitos do projeto

Requisitos do produto

Processo de

desenvolvimento

Produto de

software

Experiências passadas

Requisitos do processo

FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento deprojeto e engenharia do produto

8

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 15/101

 

Introdução

 A engenharia de processo  tem como metas a definição e a manutenção dosprocessos de uma organização. Ela deve ser capaz de facilitar a definição, a análisee a simulação de um processo, assim como estar apta a implantá-lo, avaliá-lo, medi-lo e melhorá-lo. A engenharia de processo pode ser vista como uma extensão dafunção tradicional da garantia de qualidade e trata os processos de software de uma

forma sistemática, com um ciclo de vida bem definido. Contudo, a grande maioria dasorganizações que desenvolvem software sente muita dificuldade em entender, definir e gerenciar estes processos. As empresas de software devem buscar os seuspróprios ambientes para existirem e operarem. Abordagens da indústriamanufatureira, por exemplo, não têm demonstrado serem adequadas à indústria desoftware.

O gerenciamento de projeto objetiva assegurar que processos particularessejam 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 necessários para um projetoproduzir um produto e/ou serviço, de acordo com seus requisitos. Todavia, gerenciar projetos de software é uma atividade complexa devido a uma série de fatores, taiscomo: dinamicidade do processo, grande número de variáveis envolvidas, exigênciade adaptabilidade ao ambiente de desenvolvimento e constantes alterações no quefoi planejado. Estes fatores dificultam o trabalho das equipes de desenvolvimento namedição do desempenho dos projetos, na verificação de pontos falhos, no registro deproblemas, na realização de estimativas e planejamentos adequados.

Este módulo se concentra nas áreas de engenharia de processo e

gerenciamento de projetos.

1.1 PROJETO E A GERÊNCIA DE PROJETOS

Um projeto pode ser definido como um empreendimento temporário com oobjetivo de criar um produto, serviço ou resultado único [PMBOK2000] Atemporalidade de um projeto significa que um projeto deve possuir um inicio e um fimdefinido e estabelecido. O final pode ser quando os objetivos do projeto foremalcançados, ou quando ele é cancelado (por se chegar a uma conclusão de que osobjetivos não poderão ser alcançados ou pela mudança das necessidades).

 A meta da gerência de projetos é conseguir exceder as necessidades eexpectativas dos stakeholders1[PMBOK2000]. Todavia, satisfazer ou exceder estasnecessidades envolve um balanceamento entre as várias demandas concorrentes emrelação aos itens abaixo:

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

1 Stakeholders são os indivíduos ou as organizações que estão ativamente envolvidos em um projeto,cujos interesses podem afetar positivamente ou negativamente o resultado da execução do projeto [PMBOK2000].

9

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 16/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

• stakeholders com necessidades e expectativas diferenciadas; e

• requisitos identificados (necessidades) e requisitos não identificados(expectativas).

1.2 MOTIVAÇÃO E RELEVÂNCIA DA GERÊNCIA DE PROJETOS

 Alguns estudos e pesquisas que foram realizados nos anos 1990 demonstraramque o gerenciamento de projeto é a causa mais evidente das falhas na execução eentrega de produtos e serviços de software. O SEI-Software Engineering Instituteconstatou, já em 1993, que o principal problema que aflige as organizações desoftware é gerencial e preconizou que: “as organizações precisam vencer o seuburaco negro que é o seu estilo de gerenciar de maneira informal, sem métodos esem técnicas” [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 pobregerenciamento por parte do desenvolvedor e adquirente, deixando claro que oproblema não é de desempenho técnico.

O estudo realizado pelo Standish Group [Standish1995], chamado de relatóriodo “Chaos”, focou a indústria de software comercial. Esse estudo identificou que: asempresas dos Estados Unidos gastaram $81 bilhões em projetos de software queforam cancelados em 1995; 31% dos projetos estudados foram cancelados antes deestarem concluídos; 53% dos projetos de software que foram concluídos excederammais do que 50% a sua estimativa de custo; somente 9% dos projetos, em grandes

organizações, foram entregues no tempo e orçamento previstos; para organizaçõesde pequeno e médio porte os números melhoraram em 28% e 16%, respectivamente.Este relatório aponta o gerenciamento de software como sendo a razão para osucesso ou a falha de um projeto de software.

Através de uma análise e acompanhamento de cem projetos de software,Jones [Jones1996] relata: “os seis primeiros dos dezesseis fatores associados aosdesastres do software são falhas específicas no domínio do gerenciamento deprojeto, e os três dos outros dez fatores restantes estão indiretamente associados àspraticas de gerenciamento pobre”.

Walker [Walker1997] conclui que: “o desenvolvimento de software ainda éimprevisível; somente 10% dos projetos de software são entregues com sucessodentro das estimativas de orçamento e custo; a disciplina de gerência é mais umdiscriminador de sucesso ou falha do que são os avanços tecnológicos e aquantidade de softwares jogados fora, e que tem necessidade de re-trabalho, são umindicativo de processo imaturo”.

10

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 17/101

 

Introdução

Muitas pesquisas enfatizam que o gerenciamento é a principal causa dosucesso ou fracasso dos projetos de software. Apesar disso, o gerenciamento deprojetos de software ainda é pouco abordado e praticado nas empresas de software[Machado2001]. Jones [Jones1999] destaca que a ausência de um processo degerenciamento apropriado, aliado às estimativas deficientes de custo e de tempo, é

umas das principais causas das falhas dos projetos de software.

Os principais padrões e normas para SPA/SPI (Software Process Assessment/ 

Software Process Improvement )2 têm colocado o gerenciamento de projetos como umdos requisitos básicos para que uma empresa inicie a melhoria de seu processo.Contudo, a introdução de padrões e normas dentro das organizações de software temse mostrado complexo demais, além de causar uma sobrecarga de trabalhosignificativa. Segundo Belloquin [Belloquin1999], estes padrões e normas definempráticas que devem ser realizadas, porém não determinam como executá-las.

Nós acreditamos que a existência de procedimentos padronizados e de fácilcompreensão pode ser de grande valor, fornecendo uma orientação aos gerentes deprojeto e dificultando a ocorrência de falhas graves de gerenciamento por falta deexperiência.

1.3 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE

Já em 1989, Humphrey [Humphrey1989] constatou que: “a ausência de práticas

administrativas no desenvolvimento de software é a principal causa de sérios

 problemas enfrentados pelas organizações, tais como: atrasos em cronogramas,

custo maior do que o esperado e presença de defeitos, ocasionando uma série deinconveniências para os usuários e enorme perda de tempo e de recursos”.

 Ainda hoje esta afirmação tem sido confirmada por diversos autores. Na atualcultura das organizações de software o planejamento, quando ocorre, é feito de formasuperficial [Weber1999] [Sanches2001]. Muitos projetos de software são realizadossem um planejamento de como a idéia modelada pelo levantamento de requisitos enecessidades dos clientes pode ser transformada em produto.

Os gerentes de projeto de software estão desacostumados a estimar [Vigder1994]. Quando estimam, costumam basear-se em estimativas passadas,

mesmo sabendo que elas podem estar incorretas (não sabem também precisar oquanto elas estão incorretas). Há gerentes que se recusam a estimar somente por 

 julgarem perda de tempo, uma vez que correm o risco de obter resultados incorretose, portanto, estarem desperdiçando tempo.

2 Exemplos de SPA/SPI são: CMM, CMMI, BootStrap, ISO9000, ISO/IEC15504, ISO12207, entre outros.

11

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 18/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

Boas estimativas de custo, esforço e prazo de software requerem um processoordenado que defina a utilização de métricas de software, método e ferramenta deestimativa. As empresas de software, de forma geral, não detêm conhecimentos erecursos para isso [Vigder1994].

Estimar, medir e controlar um projeto de software são tarefas difíceis, pois odesenvolvimento de software é uma atividade criativa e intelectual, com muitasvariáveis envolvidas (como metodologias, modelos de ciclo de vida, técnicas,ferramentas, tecnologias, recursos e atividades diversas). Os gerentes inexperientestentam cumprir prazos dando a máxima velocidade na fase inicial e estãodespreparados para os momentos de impasse, quando os ajustes são inevitáveis.

 A dinamicidade do processo de software dificulta também o gerenciamentoefetivo de projetos de software, devido às alterações constantes nos planos deprojetos, redistribuição de atividades, inclusão/exclusão de atividades, adaptação de

cronogramas, realocação de recursos, novos acordos com os clientes, entregasintermediárias não previstas etc. Um projeto de software também deve adaptar-se aoambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades dopessoal ou equipe.

Outros fatores ainda agravam os problemas de gerenciamento de projetos desoftware em empresas de pequeno e médio porte, tais como: inexistência de umprocesso definido, recursos pessoais e financeiros limitados, falta e/ou pouca culturaem processos, pouco treinamento em engenharia de software, imaturidademetodológica, crescimento ocorrido por demanda, falta de experiência administrativa

por parte dos gerentes e diretores e falta de definição das metas organizacionais.

1.4 ESTRUTURA DO MÓDULO

 Além deste capítulo introdutório, este módulo está organizado em mais cincocapítulos e dois apêndices. O capítulo 2 aborda padrões, normas e modelos quedefinem boas práticas para a gerência de projetos de software. Este capítulo tambémpropõe um modelo com elementos essenciais para a construção de um processo degerência de projetos. A intenção deste capítulo é apresentar ao aluno conceitos que

 julgamos importante para a criação de um bom processo de gerência de projetos de

software. Os capítulos 3, 4 e 5 apresentam um exemplo de processo de gerência deprojetos de software para empresas de pequeno e médio porte. Nestes capítulos seráapresentado o ProGer – Processo de Gerência de Projetos de Software, que é umprocesso que pode ser aplicado para empresas de pequeno e médio porte. Estes trêscapítulos objetivam mostrar ao aluno um exemplo de como um processo de gerênciade projetos de software que pode ser utilizado para melhorar o desempenho de umaempresa. Por fim, o capítulo 6 realiza uma conclusão geral sobre os temas abordadosneste módulo.

12

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 19/101

 

Introdução

EXERCÍCIOS DE FIXAÇÃO:1. Tente relembrar, sem consultar o texto deste capítulo, quais são as principais dificuldades

encontradas pelas empresas de software para gerenciar seus projetos.2. No fórum virtual, coloque algumas considerações sobre a dificuldade da gerência de projetos.

Você concorda com as dificuldades citadas neste capítulo? Existem outras dificuldades quevocê já observou e queira compartilhar conosco?

3. No início do capítulo foi apresentada uma pesquisa realizada por Gibbs em 1994. Estapesquisa demonstrou que a Engenharia de Software, em diversos aspectos, ficou estagnadadesde 1960, quando foi publicado o texto “The Software Crisis”. Os mesmos problemasapresentados em 1960 eram os de 1994. Você acha que existe algum fator histórico quemereça destaque para esta estagnação da Engenharia de Software? Você acredita que estequadro ainda é o mesmo atualmente (dez anos depois)? Vamos discutir isso no fórum?

4. Por que os modelos e padrões para SPA/SPI aconselham que se inicie o processo demelhoria com a gerência de projetos? Por que as metodologias de desenvolvimento estãosendo “colocadas” como uma etapa seguinte?

5. Gerenciar projetos de software é diferente de gerenciar projetos de manufatura? Por que

você tem esta opinião? Compartilhe suas idéias no fórum virtual.6. Neste capítulo foi apresentada uma pesquisa do Standish Group, de 1995, sobre algunsproblemas da indústria de software dos Estados Unidos. Em 2001 foi realizada uma pesquisasimilar. Você conhece esta pesquisa? Os indicadores continuam os mesmos? Como secomportou a indústria de software dos Estados Unidos de 1995 para 2001? Compartilhe estapesquisa e sua opinião no fórum virtual.

7. Você concorda com a afirmação da seção 1.1 que diz que um projeto cria um produto,serviço ou resultado ÚNICO? (Pense um pouco a respeito e depois leia a seção 1.2 doPMBOK).

8. Você concorda com a afirmação da seção 1.1 que diz que um projeto deve ter característicaTEMPORAL? (Pense um pouco a respeito e depois leia a seção 1.2 do PMBOK).

9. Qual a diferença entre “escopo do projeto” e “escopo do produto/serviço”? (pesquise noPMBOK).

13

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 20/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software14

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 21/101

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 22/101

 

2MODELOS, PADRÕES E NORMAS EA GERÊNCIA DE PROJETOS

Os estudos realizados na década de 1990 sobre gerenciamento de projetos desoftware deixaram evidente que as práticas de gerenciamento de projetos devem ser 

melhoradas para que os projetos de software tenham sucesso. Dada estapreocupação, muitos modelos e normas para SPA/SPI evoluíram, principalmente coma inclusão de práticas gerenciais para os projetos de software; exemplos são: CMM[Paulk1993] para CMMI [CMMI:2000]; o adendo à norma ISO12207 [ISO12207:1995]em 2001 [ISO12207:2000] e os novos processos de gerenciamento inseridos naISO/IEC15504 no decorrer de sua confecção.

Contudo, Machado [Machado2001] demonstrou recentemente que apesar daspesquisas evidenciarem que o problema da indústria de software é mais gerencial doque técnico, a gerência de projetos não está sendo considerada como deveria.

 Através da comparação das práticas de gerenciamento propostas nos padrões enormas para SPA/SPI com as contidas no PMBOK – Project Management Body 

Knowledge3 [PMBOK2000], concluiu-se que os requisitos de gerenciamento deprojeto não estão representados devidamente nos modelos [Machado2001]. Ogerenciamento de projeto de software tem sido priorizado há pouco tempo pelasorganizações que definem padrões e normas para software.

 A ISO/IEC15504 é quem aborda o gerenciamento de projetos de software deforma mais completa [Wang1999]. Ela estabelece um conjunto de práticas básicasque devem ser seguidas para o sucesso do gerenciamento de projetos de software.

Desta forma, optamos por destacar neste capítulo os processos de gerenciamento deprojetos proposto pela ISO/IEC15504. Este capítulo também apresentará as áreas deconhecimento do PMBOK.

2.1 PROCESSOS DE GERENCIAMENTO DA ISO/IEC155043 O PMBOK e suas áreas de conhecimento está em detalhes nas seções seguintes. O texto completo do

PMBOK se encontra no material complementar do ambiente virtual.

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 23/101

 

Modelos, Padrões e Normas e a Gerência de Projetos

Em 1993, um grupo de trabalho conjunto da ISO/IEC-International Organization

for Standardization/International Electrotechnical Commission estabeleceu um projetodenominado SPICE-Software Process Improvement and Capability Evaluation

[Dorling1993], que objetivava chegar a um consenso entre os diversos métodos deavaliação do processo de software. Este projeto, posteriormente, gerou o relatório

técnico ISO/IEC15504 [ISO/IEC15504:1-9:1998].

 A ISO/IEC15504 atualmente é uma norma que representa um padrãointernacional emergente que estabelece um framework para construção de processosde avaliação e melhoria do processo de software. Este framework pode ser utilizadopelas empresas envolvidas em planejar, gerenciar, monitorar, controlar e melhorar aaquisição, fornecimento, desenvolvimento, operação, evolução e suporte do software.

 A ISO/IEC15504 não é um método isolado  para avaliação e sua característicagenérica permite que possa ser utilizada em conjunto com uma variedade demétodos, de técnicas e de ferramentas.

Nove documentos compõem a ISO/IEC15504. Alguns têm caráter normativo(como a ISO/IEC15504-2, ISO/IEC15504-3 e ISO/IEC15504-9) e outros possuemcaráter 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 ummodelo de referência de processo e um modelo de capacitação do processo (Figura2.1) que pode compor a base para a definição e avaliação de um processo desoftware. Este modelo de referência possui uma abordagem bidimensional.

FIGURA 2.1 As dimensões do modelo de referência da ISO/IEC15504

 A primeira dimensão auxilia os engenheiros de processo na definição dosprocessos necessários em uma empresa, assim como sua adequação à

15

Nível Nome dos Atributos

5 Processo Otimizado

 Atributos de mudança do processo

 Atributos de melhoria continua

4 Processo Previsível   Atributos de medida do processo Atributos de controle do processo

3 Processo Estabelecido Atributos de definição do processo Atributos de recursos do processo

2 Processo Gerenciado Atributos de gerencimento do desempenho Atributos do gerenciamento de artefatos

1 Processo Executado Atributos de desempenho do processo Atributos de melhoria continua

0 Processo Incompleto

Processos do Ciclo de Vida

CUS SUPENG MAN ORG

Processo

.............

Categoria

X

Dimensão de Processo Dimensão de Capacidade

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 24/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

ISO/IEC15504. A segunda dimensão, similar ao CMM, tem por objetivo determinar acapacidade do processo da empresa, avaliando-o através de um conjunto deatributos preestabelecidos. Os atributos de processo estão agrupados nos níveis decapacidade e podem ser aplicados em todos os processos descritos na organizaçãopara determinar a maturidade do processo.

Cinco grupos de processos são definidos pela ISO/IEC15504-2:

1. Fornecedor-Cliente (CUS-Custormer-Supplier): são os processos que dealguma forma impactam diretamente o cliente, dentre eles o suporte paradesenvolvimento e transações de software para o cliente, fornecimento deoperações corretas e uso do produto de software ou serviço;

2. Engenharia (ENG-Engineering): esta categoria agrupa os processos queespecificam, implementam e mantém o produto de software, sua relação como sistema e a documentação do cliente;

3. Suporte (SUP-Support): são processos que podem ser empregados emalgum dos outros processos e em vários pontos no ciclo de vida do software,objetivando dar suporte a eles;

4. Gerenciamento (MAN-Management): são processos que contêm práticasgerenciais que podem ser utilizadas por alguém que gerencia algum tipo deprojeto ou processo dentro do ciclo de vida do software;

5. Organização (ORG-Organization): são processos que estabelecem asfinalidades dos processos de desenvolvimento e da organização, do produto edos recursos que, quando utilizados por projetos na organização, realizarão asmetas do negócio.

 A categoria de processo MAN (Management process category ) é quemestabelece os processos de gerenciamento para a empresa, que estão subdivididosem quatro grupos:

MAN.1 Processo de gerenciamento – organiza, monitora e controla o início e odesempenho de qualquer processo ou função dentro da empresa, alcançando asmetas do negócio de maneira efetiva;

MAN.2 Gerenciamento de projetos – identifica, estabelece, coordena e monitora

atividades e recursos necessários para que um projeto realize um produto ou serviçode acordo com seus requisitos;

MAN.3 Gerenciamento da qualidade – monitora a qualidade dos produtos eserviços realizados pelos projetos e garante que eles satisfaçam ao cliente;

MAN.4 Gerenciamento de riscos – identifica e mitiga os riscos dos projetos,continuamente, através do ciclo de vida de um projeto.

16

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 25/101

 

Modelos, Padrões e Normas e a Gerência de Projetos

 Apesar dos quatros agrupamentos estarem envolvidos no gerenciamento deprojetos, vamos descrever apenas o grupo MAN.2, que está subdividido em 12práticas básicas:

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 atingidasconsiderando os recursos disponíveis e as restrições;

MAN.2.BP2 – Determina a estratégia de desenvolvimento, avaliando as opçõesdisponíveis para alcançar as metas do projeto, estabelecendo os riscos e asoportunidades que a estratégia 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

necessários para completar o trabalho, avaliando as opções disponíveis para alcancedas metas do projeto e levando em consideração os riscos e as oportunidades;

MAN.2.BP5 – Estabelece a estrutura de divisão do trabalho, as entregas e aseqüência das tarefas, levando em conta os recursos requeridos e a estratégiaadotada;

MAN.2.BP6 – Identifica os requisitos da infra-estrutura, ou seja, os elementosdo ambiente e os recursos humanos necessários para suportar a estratégia e aexecução do projeto;

MAN.2.BP7 – Estabelece o cronograma do projeto, baseado na estrutura dedivisão do trabalho, estimativas realizadas e elementos da infra-estruturaconsiderados;

MAN.2.BP8 – Aloca responsabilidades, identificando os indivíduos específicos eos grupos necessários para garantir a realização do que foi acordado no projeto;

MAN.2.BP9 – Identifica as interfaces entre os elementos no projeto e comoutros projetos e unidades organizacionais;

MAN.2.BP10 – Estabelece e implementa os planos de projeto, fornecendo um

mecanismo para garantir que os projetos serão formalmente desenvolvidos,implementados, mantidos e estando disponíveis para todos os envolvidos no projeto;

MAN.2.BP11 – Compara o planejado no plano de projeto com o que está sendoexecutado;

MAN.2.BP12 – Corrige os desvios quando os objetivos do projeto não estãosendo alcançados.

17

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 26/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

Os processos de gerenciamento começam a ser necessários na ISO/IEC15504somente a partir do nível 2 de capacidade e estão distribuídos conforme mostra aTabela 2.1. 

TABELA 2.1 Distribuição dos processos de gerenciamento nos níveis de

capacidade da ISO/IEC15504Níveis de Capacidade Categorias de Processo de Gerenciamento

1. Processo Executado

2. Processo Gerenciado MAN.1, MAN.2, MAN.3, MAN.4

3. Processo Estabelecido MAN.1, MAN.2

4. Processo Previsível MAN.2, MAN.3, MAN.4

5. Processo Otimizado MAN.3

2.2 PMBOK

O PMI – Project Management Institute é uma associação de profissionais degerenciamento de projetos que existe desde 1969. Esta associação criou em 1986 aprimeira versão do PMBOK – Project Management Body of Knowledge4. O PMBOK éum guia que descreve a somatória de conhecimento e as melhores práticas dentro daprofissão de gerenciamento de projetos. É um material genérico que serve para todasas áreas de conhecimento, ou seja, tanto para construção de um edifício como para aprodução de software.

 A meta do gerenciamento de projetos, segundo o PMBOK, é conseguir exceder as necessidades e expectativas dos stakeholders. Todavia, como já visto no capítulo

1, satisfazer ou exceder estas necessidades envolve um balanceamento entre asvárias demandas concorrentes em relação:

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

• stakeholders com necessidades e expectativas diferenciadas; e

• requisitos identificados (necessidades) e requisitos não identificados(expectativas).

O PMBOK [PMBOK2000] organiza os processos de gerenciamento de projetos

em cinco grupos (figura 2.2): processos de inicialização, processos de planejamento,processos de execução, processos de controle e processos de finalização.

42 O PMBOK é o material mais importante que foi gerado pelo PMI, contudo, esta instituição possuidiversos outros documentos e relatos que são bastante relevantes para a gerência de projetos. Para seaprofundar no assunto, você pode consultar o material complementar do ambiente virtual ou visitar o sitehttp://www.pmi.org/ .

18

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 27/101

 

Modelos, Padrões e Normas e a Gerência de Projetos

FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK

Os processos de inicialização autorizam o início do projeto ou de uma fase doprojeto. Os processos de planejamento definem e refinam os objetivos do projeto,

selecionando as melhores alternativas para realizá-lo. Os processos de execuçãocoordenam pessoas e outros recursos para a realização do projeto, baseando-se noplanejamento. Os processos de controle monitoram e medem o progresso do queestá sendo executado, com o intuito de tomar ações corretivas quando necessárias.Os processos de finalização formalizam o aceite e a finalização do projeto ou de uma

fase do projeto.

Os processos do PMBOK estão organizados por áreas de conhecimento, que sereferem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentrodestas áreas de conhecimento os cinco grupos de processos acima descritos podemocorrer. A figura 2.3 mostras as 9 áreas de conhecimento do PMBOK.

 A seguir descreveremos os processos de cada área de conhecimento doPMBOK. Todos os processos descritos, das áreas abaixo, interagem uns com osoutros e também com os processos das demais áreas de conhecimento. Cadaprocesso pode envolver esforço de um ou mais indivíduos ou grupos de indivíduos,dependendo das necessidades do projeto. Cada processo, geralmente, ocorre pelomenos uma vez em cada fase do projeto.

2.2.1 Gerência de integração de projetos

19

Processos deInicialização

Processos dePlanejamento

Processos de

controle

Processos de

execução

Processos de

finalização

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 28/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

 A gerência de integração engloba os processos necessários para garantir queos vários elementos de um projeto sejam propriamente coordenados. Objetivarealizar as negociações dos conflitos entre objetivos e alternativas do projeto com afinalidade de atingir ou exceder as necessidades e expectativas de todas as partesinteressadas. Envolve o desenvolvimento e a execução do plano de projeto e o

controle geral das mudanças.

Essa área de processo incluiu os seguintes processos principais:

• desenvolvimento do plano do projeto - agregar os resultados dos outrosprocessos de planejamento, construindo um documento coerente econsistente;

• execução do plano do projeto - levar a cabo o projeto através darealização das atividades nele incluídas;

• controle geral de mudanças - coordenar as mudanças através do projeto

inteiro.

FIGURA 2.3 Áreas do gerenciamento de projetos do PMBOK

2.2.2 Gerência de escopo de projetos

 A gerência do escopo do projeto inclui os processos requeridos para assegurar que o projeto inclua todo o trabalho necessário, e tão somente o trabalho necessário,para complementar de forma bem sucedida o projeto. A preocupação fundamentalcompreende definir e controlar o que está ou não incluído no projeto.

Essa área de processo incluiu os seguintes processos principais:

Gerência de

Escopo

Gerência de

Projeto

Gerência de

Integração

Gerência de

Tempo

Gerência de

Qualidade

Gerência de

Custo

Gerência deRecursosHumanos

Gerência de

Risco

Gerência de

Comunicação

Gerência de

 Aquisição

20

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 29/101

 

Modelos, Padrões e Normas e a Gerência de Projetos

• iniciação - comprometer a organização a iniciar a próxima fase do projeto;

• planejamento do escopo - desenvolver uma declaração escrita do escopocomo base para decisões futuras do projeto;

• detalhamento do escopo - subdividir os principais subprodutos do projetoem componentes menores e mais manejáveis;

• verificação do escopo - formalizar a aprovação do escopo do projeto;

• controle de mudanças de escopo - controlar as mudanças do escopo doprojeto.

2.2.3 Gerência de tempo de projetos

 A gerência de tempo do projeto objetiva garantir o término do projeto no tempocerto. Consiste da definição, ordenação e estimativa de duração das atividades e deelaboração e controle de cronogramas.

Essa área incluiu os seguintes processos principais:

• definição das atividades - identificar as atividades específicas que devemser realizadas para produzir os diversos subprodutos do projeto;

• seqüenciamento das atividades - identificar e documentar as relações dedependência entre as atividades;

• estimativa da duração das atividades - estimar a quantidade de períodosde trabalho que serão necessários para a implementação de cada atividade;

• desenvolvimento do cronograma - analisar a seqüência e as durações das

atividades e os requisitos de recursos para criar o cronograma do projeto;• controle do cronograma - controlar as mudanças no cronograma do

projeto.

2.2.4 Gerência de custo de projetos

 A gerência de custo tem por objetivo garantir que o projeto seja executadodentro do orçamento aprovado. Consiste no planejamento dos recursos, estimativa,orçamento 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 paraexecutar as atividades do projeto;

• estimativa dos custos - desenvolver uma estimativa dos custos dosrecursos necessários à implementação das atividades do projeto;

21

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 30/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

• orçamento dos custos - alocar as estimativas de custos globais aos itensindividuais de trabalho;

• controle dos custos - controlar as mudanças no orçamento do projeto.

2.2.5 Gerência da qualidade de projetos

 A gerência da qualidade objetiva garantir que o projeto satisfará as exigênciaspara as quais foi contratado. Consiste no planejamento, garantia e controle dequalidade.

Essa área de processo incluiu os seguintes processos principais:

• planejamento da qualidade - identificar quais padrões de qualidade sãorelevantes para o projeto e determinar a forma de satisfazê-los;

• garantia da qualidade - avaliar periodicamente o desempenho geral doprojeto, buscando assegurar a satisfação dos padrões relevantes de

qualidade;• controle da qualidade - monitorar os resultados específicos do projeto para

determinar se eles estão de acordo com os padrões de qualidade relevantese identificar as formas para eliminar as causas de desempenhosinsatisfatórios.

2.2.6 Gerência de recursos humanos de projetos

 A gerência de recursos humanos objetiva garantir o melhor aproveitamento daspessoas envolvidas no projeto. Consiste no planejamento organizacional, alocaçãode pessoal e definição de equipe.

Essa área de processo incluiu os seguintes processos principais:

• planejamento organizacional - identificar, documentar e designar asfunções, responsabilidades e relacionamentos de reporte dentro do projeto;

• montagem da equipe - conseguir que os recursos humanos necessáriossejam designados e alocados ao projeto;

• desenvolvimento da equipe - desenvolver habilidades individuais e dogrupo para aumentar o desempenho do projeto.

2.2.7 Gerência de comunicação de projetos

 A gerência de comunicação tem por objetivo principal garantir a geraçãoadequada e apropriada, coleta, disseminação, armazenamento e disponibilização dainformação.

Essa área de processo incluiu os seguintes processos principais:

22

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 31/101

 

Modelos, Padrões e Normas e a Gerência de Projetos

• planejamento das comunicações - determinar as informações ecomunicações necessárias para os interessados: quem necessita de qualinformação, quando necessitarão dela e como isso será fornecido;

• distribuição das informações - disponibilizar as informações necessáriaspara os interessados do projeto da maneira conveniente;

• relato de desempenho - coletar e disseminar as informações dedesempenho. Inclui relatórios de situação, medição de progresso eprevisões;

• encerramento administrativo - gerar, reunir e disseminar informações paraformalizar a conclusão de uma fase ou de todo o projeto.

2.2.8 Gerência de risco de projetos

 A gerência de risco objetiva maximizar os resultados de ocorrências positivas e

minimizar as conseqüências de ocorrências negativas. Consiste na identificação,quantificação, tratamento e controle dos riscos do projeto.

Essa área de processo incluiu os seguintes processos principais:

• identificação dos riscos - determinar quais os riscos são mais prováveis deafetar o projeto e documentar as características de cada um;

• quantificação dos riscos - avaliar os riscos, suas interações e possíveisconseqüências;

• desenvolvimento das respostas aos riscos - definir as melhoriasnecessárias para o aproveitamento de oportunidades e respostas às

ameaças;

• controle das respostas aos riscos - responder às mudanças nos riscos nodecorrer do projeto.

2.2.9 Gerência de aquisição de projetos

 A gerência de aquisição tem por objetivo principal obter bens e serviçosexternos à organização executora. Consistem na seleção de fornecedores,planejamento de aquisição, planejamento de solicitação, solicitação de propostas eadministração e encerramento de contratos.

Essa área de processo incluiu os seguintes processos principais:

• planejamento das aquisições - determinar o que contratar e quando;

• preparação das aquisições - documentar os requisitos do produto eidentificar os fornecedores potenciais;

• obtenção de propostas - obter propostas de fornecimento conformeapropriado a cada caso (cotações de preço, cartas-convite, licitação);

23

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 32/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

• seleção de fornecedores - escolher entre os possíveis fornecedores;

• administração dos contratos - gerenciar o relacionamento com osfornecedores;

• encerramento do contrato - completar e liquidar o contrato incluindo aresolução de qualquer item pendente.

2.3 MODELAGEM DO SISTEMA DE PROCESSOS DE EMPRESA DESOFTWARE

Como já estudado anteriormente em outros módulos do curso, um processopode ser definido como um conjunto de atividades inter-relacionadas quetransformam um conjunto de entradas em resultados [ISO12207:1995]. Segundo aISO15504 [ISO15504:1-9:1998], processo de software é um conjunto de processosutilizados por uma organização de software ou um projeto de software para planejar,gerenciar, executar, monitorar, controlar e melhorar as atividades que estão

relacionadas com software.

O trabalho de Wang [Wang1999] apresenta um framework  unificado de umsistema de processo para uma organização de software. A figura 2.4 mostra estemodelo, que está dividido em três agrupamentos principais: o modelo do processo, omodelo de avaliação do processo e o modelo de melhoria do processo.

FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa desoftware

O modelo do processo  é utilizado para descrever a organização, suacategoria, sua hierarquia, o inter-relacionamento e as instâncias dos seus processos.

Modelo de

melhoria

baseado em

avaliação

Método de

determinação

da capacidade

do processo

Subsistema do

processo de

gerenciamento

Subsistema do

processo de

desenvolvimento

Modelo de

melhoria

baseado em

Benchmark

Subsistema do

processo

organizacional

 Agregação dacapacidade da

organização

 Agregação decapacidade do

projeto

Determinaçãoda capacidade

do processo

Escala dodesempenho

da pratica

Escopo dacapacidade do

processo

Escala dacapacidade do

processo

Modelo do processo

Modelagem do sistema de

processo

Modelo de avaliação do

processo

Modelo de melhoria do

processo

Modelo de

capacidade do

processo

24

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 33/101

 

Modelos, Padrões e Normas e a Gerência de Projetos

O modelo de processo descrito por [Wang1999] identifica três conjuntos desubsistemas: processo organizacional, processo de desenvolvimento de software eprocesso de gerenciamento. Os processos organizacionais regulam as atividades quesão geralmente praticadas em uma empresa acima do nível de projeto. Os  processos

de desenvolvimento e de gerenciamento são interativos e, em paralelo, atuam sobre

o projeto.

O modelo de avaliação do processo  serve para definir procedimentos paraavaliar os pontos fortes e fracos dos processos da organização, além de identificar ospontos para melhoria. Através do modelo de melhoria do processo  podem-sedefinir procedimentos sistemáticos para uma efetiva melhoria do desempenho dosprocessos da empresa mudando os processos correntes ou adicionando a eles novosprocessos para correção ou melhoria de problemas identificados. O processo demelhoria vem a seguir do processo de avaliação e o relacionamento entre eles formaum ciclo repetitivo até o processo da organização estar otimizado. Exemplo é o plan-

do-check-act descrito por Campos [Campos1992].

Diversos modelos, normas e padrões definem certificação, avaliação e melhoriapara o processo de software, entre eles podemos citar: a ISO9000 [ISO9000-3:1997],CMM/CMMI [Paulk1993] [Paulk1997] [CMMI:2000], ISO15504 [ISO15504:1-9:1998] eBootStrap [Kuvaja1993] [Kuvaja1994].

 Apesar das empresas de software durante muito tempo negligenciarem aespecificação e o gerenciamento de seus processos, estes sempre existiram. Porém,não há um consenso de que tipo de processo de software deva ser utilizado em uma

organização, pois alguns processos se adequam melhor a certos tipos de aplicaçõesdo que outros. Além disso, uma empresa pode, inclusive, possuir diversos padrões deprocessos de software sendo utilizados em projetos distintos.

O reconhecimento das necessidades dos modelos de processo de software temdeixado um amplo campo de trabalho em muitas direções. As organizações quedesenvolvem software têm verificado que definindo seus processos podem melhorar sua eficácia e a qualidade dos produtos e serviços que realizam.

 A seção seguinte apresenta um modelo que utilizaremos nos próximos capítulospara definir um processo para gerência de projetos para uma empresa de software, o

ProGer - Processo de Gerência de Software.

2.4 ELEMENTOS ESSENCIAIS PARA CRIAR UM PROCESSO DE GERÊNCIA DEPROJETOS

25

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 34/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

 Algumas propostas de processo para gerência de projetos de software podemser encontradas na literatura. O fluxo de gerência de projetos do RUP [RationalUnified Process] é um exemplo. Contudo, estes processos não devem ser adotadosem uma empresa sem que se leve em consideração alguns outros elementos que

 julgamos essenciais.

Desta forma, propomos que ao criar um processo de gerência de projetos   parauma empresa de software deve-se considerar seis elementos essenciais, comomostra a Figura 2.5: a política organizacional, os padrões, o processo degerenciamento, os procedimentos, os treinamentos, e as ferramentas5.

PolíticaOrganizacional

Treinamento

Procedimentos

Ferramentas de gerenciamentode projetos de software

Processo de gerenciamento deprojetos de software

Padrões

restringe o processo

é implementado através de

são apoiados por 

FIGURA 2.5 Modelo para criação de processo de gerenciamento de projetos desoftware

 A  política organizacional  estabelece as leis e as regras que governam ourestringem as operações da empresa. Ela identifica os requisitos aceitáveis doprocesso e/ou formas de se realizar o projeto. A política organizacional estabelecetambém as metas e os objetivos que a organização deseja alcançar.

Os padrões definem as operações e os critérios de aceitação para a execução

de serviços e produtos da empresas. Os padrões e normas para SPA/SPI e asmetodologias podem, por exemplo, ser utilizados para a definição dos padrões daorganização.

5 Esta recomendação se aplica também a outras áreas de processo e não somente a gerência deprojetos.

26

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 35/101

 

Modelos, Padrões e Normas e a Gerência de Projetos

Um  processo de gerenciamento de projetos de software descreve como aorganização gerencia a execução de seus serviços e produtos, de acordo com apolítica organizacional e os padrões adotados.

Nos capítulos seguintes definiremos o ProGer, que é um modelo para gerência

de projetos de software. O ProGer pode auxiliar as empresas de software naorganização inicial de seu negócio através do uso de artefatos de alto nível e debaixa complexidade, em conjunto com um modelo de ciclo de vida para os projetos eo estabelecimento de fluxos de trabalho.

Os processos são implementados através de  procedimentos. Os fluxos detrabalho, por exemplo, podem especificar esses procedimentos, ou seja, asinstruções passo-a-passo de como o processo deve ser executado. A políticaorganizacional é que restringe e expande o processo de gerência de projetos,adaptando-o à realidade da empresa e estabelecendo procedimentos específicos,

dependendo do projeto. As ferramentas determinam algum apoio automatizado para os procedimentos

do processo, seja auxiliando na execução das atividades como para obtenção demétricas para posterior avaliação do processo.

Os treinamentos possibilitam dar aos recursos humanos da empresa oconhecimento e habilidades necessárias para executarem os procedimentos doprocesso.

2.5 CONSIDERAÇÕES

Como já dito anteriormente neste capítulo, os padrões e normas para SPA/SPIpodem ser utilizados com o intuito de definir, avaliar e melhorar os processos de umaempresa. Todavia, apesar da sua importância, eles ainda estão sendo poucoconsiderados pelas empresas [Lindvall2000]. Diversos motivos dificultam o usodestes padrões, dentre eles o fato de que a definição e uso de um processo desoftware envolvem uma complexa inter-relação de fatores organizacionais, culturais,tecnológicos e econômicos.

 A complexidade destes modelos também dificulta sua implantação em empresas

de pequeno porte, já que foram construídos para o âmbito de empresas estruturadase estabilizadas. Porém, acreditamos que a grande ameaça à implantação destespadrões e normas, nas empresas, é o dia-a-dia da empresa que absorvepraticamente todos os recursos existentes. Sendo esse um projeto interno, de longoprazo e com resultados também de longo prazo, há uma tendência à acomodação,fazendo com que as atividades sejam proteladas por diversas vezes até adesistência.

27

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 36/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

No que se refere ao gerenciamento de projetos de software especificamente,estamos de acordo com as conclusões realizadas nos trabalhos [Fernandes1989] e[Maidantchik1999]: “apesar do esforço da comunidade de engenharia de software emdefinir modelos e padrões para a construção de um efetivo processo degerenciamento de projetos, a maioria das empresas ainda sente dificuldade em

definir os seus processos e não gerenciam os seus projetos de forma satisfatória”.

O gerenciamento de projetos de software é, de fato, pouco abordado e praticadoe, porque não dizer, negligenciado. Os ambientes tradicionais das empresas têmdado suporte, em geral, somente à engenharia, assumindo um processo implícito etendo como foco principal o produto. Acreditamos que esta visão limita as empresasno que diz respeito à tomada de decisões, ao estabelecimento e obtenção de metasorganizacionais, à determinação de pontos para melhoria, à estipulação de prazospara entrega de produtos e até mesmo à obtenção de uma certificação.

O PMBOK e os modelos de SPA/SPI podem ser utilizados para criar umprocesso padrão para gerenciamento de projetos de software. Estes modelos reúnemboas práticas para as empresas. Contudo, a implantação destes padrões exige uminvestimento importante dos envolvidos, para conceber um processo que venhaalavancar o negócio, facilitar a vida dos envolvidos e não criar burocracia somentepara atender aos requisitos descritos no modelo. Além disso, estes modelosdescrevem “o que” deve ser feito e não “como” fazê-lo.

 Algumas iniciativas já foram realizadas com o intuito de descrever o “como”utilizar normas e padrões de SPA/SPI em uma empresa. Contudo, estes frameworks

acabam sendo tão complexos quanto os modelos que os originou e estão descritostambém para o âmbito de empresas estruturadas.

Os próximos capítulos deste módulo apresentam um exemplo de processo paragerência de projetos de software que foi construído considerando os seis elementosessenciais apresentados neste capítulo. O capítulo 3 define a política organizacionale os padrões adotados. O capítulo 4 traz o processo propriamente dito, com seumodelo de ciclo de vida para os projetos, fluxos de trabalho, artefatos, stakeholders,métricas, etc. O capítulo 5 relaciona algumas ferramentas que podem ser utilizadasem conjunto com o processo.

 

28

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 37/101

 

Modelos, Padrões e Normas e a Gerência de Projetos 29

EXERCÍCIOS DE FIXAÇÃO:1. Considerando o ambiente em que trabalha, que práticas básicas da ISO/IEC15504 de

gerência de projetos você acredita estar satisfazendo?2. Considerando que uma das maiores dificuldades da gerência de projetos de software é a

constante mudança do escopo, leia a área de conhecimento “Gestão de Escopo” do

PMBOK e coloque a sua opinião sobre o que acredita ser aplicável para empresas desoftware no fórum 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 idéia nofórum virtual de como você poderia institucionalizá-la em sua empresa (ou departamento).

4. Você concorda com os elementos essenciais para a criação de um processo para gerênciade projetos? Que elementos você julga estar faltando? Que elementos vocêdesconsideraria? (Coloque a sua opinião no fórum virtual).

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 38/101

 

3POLÍTICA ORGANIZACIONAL EPADRÕES ADOTADOS PARA A

DEFINIÇÃO DO PROGER

Este capítulo apresenta a política organizacional e as metas adotadas para a

criação do processo de gerência de projetos de software, denominado ProGer. Estecapítulo estabelece dois dos seis elementos essenciais definidos na seção 2.4 destemódulo.

3.1 POLÍTICA ORGANIZACIONAL CONSIDERADA PARA O PROGER

Como visto no capítulo anterior, a política organizacional estabelece as leis eregras que governam ou restringem as operações da empresa de software. Elaidentifica os requisitos aceitáveis do processo e/ou formas de se realizar o projeto. Apolítica organizacional estabelece também as metas e os objetivos que a empresa

deseja alcançar. De forma simplista, vamos definir a política organizacional baseadoem dois aspectos: (1) caracterização da empresa e (2) metas que a empresapretende atingir com a gerência de projetos.

3.1.1 Caracterização da empresa

O modelo de processo para gerenciamento de projetos de software apresentadoneste módulo deverá ser aplicável para empresas de pequeno e médio porte. Aclassificação do porte de uma empresa de software pode ser realizada considerandodiversos fatores, entre eles podemos citar: faturamento, força de trabalho e

comercialização anual bruta. Nós adotamos a classificação do porte da empresabaseada na força de trabalho, dada pelo MCT-Ministério da Ciência e Tecnologia[MCT]:

• micros – de 1 a 10 pessoas;

• pequenas – de 11 a 50 pessoas;

• médias – de 50 a 100 pessoas;

• grandes – mais de 100 pessoas.

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 39/101

 

Política Organizacional e Padrões Adotados para a definição do ProGer 

Nós optamos por considerar estas classes de empresas de software devido aofato de serem a grande maioria. A Figura 3.1 apresenta um gráfico, também retiradodo [MCT], que mostra a predominância deste tipo de organização com percentuaissuperiores a 80%, desde 1995.

20

8

13

3841

35

6

19

42

36

7

15

43

30

7

20

Micro Pequena Média Grande

       P     e     r     c     e     n      t     u     a       l

1993

1995

1997

1999

FIGURA 3.1 Porte das empresas, segundo a força de trabalho efetiva

O MCT ainda preconiza que se forem considerados os serviços terceirizados,que são muito comuns nas áreas de produção de serviços e produtos de software, o

percentual de empresas de grande porte diminui significativamente, aumentando o rolde empresas de pequeno e médio porte. Estudos realizados também em outrospaíses, como o de [Standish1995], também estabeleceram a predominância deempresas de pequeno e médio porte no setor computacional.

Outras motivações nos fizeram optar por abordar, para o nosso exemplo, asempresas de pequeno e médio porte. Segundo Laitinen [Laitinen2000], as empresasdesta classe são as que mais urgentemente necessitam de formalização deprocedimentos para gerenciamento e controle de seus projetos. Também afirma que,a utilização de padrões e normas para SPA/SPI está sendo pouco considerada por 

esta classe de empresas [Lindvall2000]. Devido ao fato destes modelos terem sidooriginalmente desenvolvidos para o âmbito de empresas bem estruturadas edepartamentalizadas, ou seja, tipicamente para o âmbito de grandes empresas, issodificulta ainda mais a orientação para empresas de pequeno e médio porte[Belloquim1999].

Outros fatores ainda agravam os problemas de gerenciamento de projetos desoftware em empresas de pequeno porte, tais como: inexistência de um processo

31

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 40/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura emprocessos, pouco treinamento em engenharia de software, imaturidade metodológica,crescimento ocorrido por demanda, falta de experiência administrativa por parte dosgerentes e diretores e falta de definição das metas organizacionais.

Consideramos também que a empresa para a qual estamos criando o processode gerência de projetos atua no mercado da seguinte forma:

• desenvolve produtos baseados nas necessidades específicas dos clientes,tipo atelier;

• possui produtos próprios que são customizados para as necessidadesespecíficas dos clientes;

• presta serviços de instalação de sistemas de outras empresas.

Outras características que consideramos para esta empresa:

• possui projetos de curta, média e longa duração;

• não utiliza metodologia para desenvolvimento de software;

• possui uma diretoria comprometida em melhorar o processo de software eintroduzir padrões.

3.1.2 Metas pretendidas com a gerência de projetos

 As principais metas que pretendemos alcançar com a implantação do processode gerência de projetos seriam tornar possível (através de um modelo simplificado deprocesso de gerenciamento de projetos de software) obter em uma empresa de

pequeno e médio porte:• melhoria da satisfação do cliente;

• melhoria da qualidade dos produtos gerados;

• melhoria da qualidade do processo;

• melhoria do gerenciamento dos recursos humanos;

• melhoria da comunicação interna e externa da empresa;

• melhoria do desempenho das estimativas de esforço, custo e prazo;

• melhoria do estabelecimento das metas organizacionais;

• melhoria na identificação dos riscos.

3.2 MODELOS, NORMAS E PADRÕES UTILIZADOS PARA A DEFINIÇAO DOPROGER

O ProGer, modelo que será apresentado no próximo capítulo, foi concebidoconsiderando os padrões da engenharia de processo e do gerenciamento deprojetos. Foi especificado tendo como base os modelos e padrões de SPA/SPI,

32

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 41/101

 

Política Organizacional e Padrões Adotados para a definição do ProGer 

principalmente, a ISO15504 [ISO15504:1-9:1998] e o CMM–Capability Maturity Model 

[Paulk1993], as metodologias para desenvolvimento de software (como o RUP-Rational Unified Process [Philippe1998] e o OPEN Process [Graham1999]), osprocedimentos 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 empíricos realizados em empresas desoftware de pequeno e médio porte.

Inicialmente para a especificação do ProGer, realizamos um estudo vertical nasnormas e padrões para SPA/SPI, considerando somente o gerenciamento de projetospara a construção de nosso modelo padrão. Contudo, nós observamos através deestudos empíricos que os padrões e normas para SPA/SPI eram insuficientes comoinsumo básico para a definição de um modelo padrão para o gerenciamento deprojetos em uma empresa. Um trabalho que enfatiza esta observação é apresentadopor Machado [Machado2001] que apresenta a relação das áreas de conhecimento do

PMBOK em comparação com dois importantes modelos, o CMM e a ISO/IEC15504(ver tabela 3.1).

Machado [Machado2001] afirma, e nós concordamos com ele, que ainda temosmuito que evoluir em relação às práticas de gerência para alcançarmos oconhecimento contido no PMBOK. Desta forma, passamos a considerar os processosdescritos no PMBOK para o ProGer. Porém, apesar do PMBOK ser um guia maiscompleto na área de gerenciamento de projetos ele não considera as peculiaridadesda execução de serviços e produtos de software. Nós, então, unificamos estes doisuniversos em um meta-processo que levou em consideração a simplicidade e

facilidade para ser utilizado em empresas de pequeno e médio porte.

 A seguir mostraremos uma tabela comparativa entre as áreas deconhecimento do PMBOK, o CMM e a ISO/IEC15504.

33

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 42/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

TABELA 3.1 Comparação entre as áreas de conhecimento do PMBOK, o CMMe a ISO/IEC15504

PMBOK CMM ISO/IEC15504

Integração Gerência de projeto integrada Gerência organizacional

Escopo Planejamento de acompanhamentoGerência de requisitos

Gerência de projetoGerência de Requisitos

Tempo Acompanhamento e controle.Mas, não endereça especificamente essaquestão

Gerência de projeto.Mas, não endereçaespecificamente essa questão.

Custo Acompanhamento e controle.Mas, não endereça especificamente essaquestão

Gerência de projeto.Mas, não endereçaespecificamente essa questão.

 Aquisição Gerência de Contratos com fornecedores Não tem processos que trateespecificamente essa questão.

Ela é coberta na norma pela Aquisição e Fornecimento e égerenciada da mesma forma queum projeto interno à organização

RecursosHumanos

 A própria concepção do modelo diz que devemse ter habilidades para executar, mas nãomenciona explicitamente a necessidade degerenciamento de recursos humanos através dosprojetos da organização

Recursos HumanosGerência do Conhecimento

Comunicação Gerência de Configuração cobre parcialmenteesse processo. A própria concepção do modelodiz que os processos devem ser comunicados,

mas não menciona explicitamente a necessidadede comunicação dos produtos dos projetos paratodos os envolvidos

Gerência de Configuração cobreparcialmente esse processo.Mas, não menciona explicitamente

esse processo

Risco Gerência de Risco Gerência de Risco

Garantia deQualidade

Garantia de qualidade de produto e processo Gerência da Qualidade

34

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 43/101

 

Política Organizacional e Padrões Adotados para a definição do ProGer 35

EXERCÍCIOS DE FIXAÇÃO:

1. Que outros elementos você consideraria para definir a política organizacional para aconstrução de um processo de gerência de projetos de software? Você acha que acaracterização da empresa e as metas (como apresentado neste capítulo) são suficientes?

Discuta no fórum virtual suas sugestões e opiniões.

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 44/101

 

4PROGER: PROCESSO DE GERÊNCIADE PROJETOS DE SOFTWARE

Este capítulo apresenta o ProGer - Processo de Gerência de Projetos deSoftware, que é um exemplo de modelo de processo para gerência de projetos de

software para pequenas e médias empresas de software. Este modelo pode auxiliar as empresas de software na organização inicial de seu negócio. O ProGer estáapresentado neste capítulo através de: um modelo de ciclo de vida para os projetos(seção 4.1); da definição dos stakeholders (seção 4.2); da definição dos fluxos detrabalho (seção 4.4); dos artefatos gerados no processo (seção 4.3) e de sugestõesde estimativas e métricas para avaliação do desempenho da execução dos projetos(seção 4.4).

Nós objetivamos com este capítulo fornecer um exemplo prático de como sepode definir um processo para a gerência 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 projetostem por objetivo definir o início e o fim de um projeto. Este modelo pode ser divididoem 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 são: o modelo espiral [Boehm1988] e o modelo

baseado em contrato [Graham1999]. O PMBOK [PMBOK2000] reconhece estesmodelos como sendo representativos para o desenvolvimento de projetos desoftware. Como tal, eles estão muito focados na construção de um produto ou serviçode software, isto é, estão fortemente associados aos aspectos da engenharia edesconsideram etapas do projeto que antecedem e sucedem a confecção do produtopropriamente dito. Estas etapas são importantes para que uma empresa possarealizar uma avaliação mais eficaz do projeto.

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 45/101

 

PROGER: Processo de Gerência de Projetos de Software

Nós definimos um modelo de ciclo de vida para projetos de softwareidentificando fases desconsideradas nos modelos tradicionais, ou mesmoconsiderados superficialmente, como é o caso do RUP-Rational Unified Process. OProGer está dividido em cinco fases distintas (Figura 4.1): a prospecção, a proposta,a execução, a garantia e o encerramento. Em todas as fases devem ser aplicadas as

etapas do modelo de processo para gerenciamento de projetos proposto peloPMBOK [PMBOK2000].

Um projeto de software pode ser iniciado em qualquer uma das fases, comexceção do encerramento. É permitido que fases possam ser eliminadas do projeto,isto é, não há imposição de um fluxo rígido a ser seguido. A seguir, descreveremoscada uma das fases do modelo de ciclo de vida. Os artefatos gerados em cada faseestão representados na seção 4.1 deste capítulo.

FIGURA 4.1 Modelo de ciclo de vida de projetos de software

 A fase de  prospecção é o período do ciclo de vida do projeto no qual sãoidentificadas as necessidades de um cliente, ou uma demanda de mercado épercebida pela empresa. A construção de um protótipo para uma demandaobservada pela empresa é um exemplo de atividade desta fase. A característica

principal desta fase é a ausência de um pedido formal por parte de um cliente, isto é,uma requisição comercial. Nesta fase já se inicia o esforço técnico e comercial daempresa. Palestras sobre produtos, construção de protótipos e levantamento derequisitos são exemplos de atividades que podem ocorrer nesta fase. Os elementosda empresa que podem estar envolvidos nesta etapa são: gerentes, diretores etécnicos.

37

Proposta

Encerrament

Garantia

Execução

Prospecção

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 46/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

Considerando os processos de gerenciamento do PMBOK [PMBOK2000], ainicialização desta fase é dada por requisições informais de clientes, solicitação deapresentação de produtos e identificação de uma demanda aprovada pela diretoriada empresa. O planejamento desta fase é bastante diverso, podendo ir desde simplesagendamentos de reuniões até a confecção de planos de projeto para execução de

um protótipo. A execução é determinada por palestras, apresentação de produtos econstrução de protótipos. A finalização ocorre quando o cliente envia um pedidoformal para a execução de um serviço ou produto, o cliente avisa que não deseja oque foi apresentado ou a empresa estabelece a continuidade ou descontinuidade doesforço para uma demanda que foi observada.

Na fase de proposta, ocorre a formalização de uma proposição da empresapara um determinado cliente interno ou externo. As características principais destafase são: a existência de uma requisição formal, a delimitação do escopo do projeto eo processo decisório do que deverá ser realizado. As atividades principais desta fase

são a elicitação ou refinamento dos requisitos, e a confecção de propostas técnicas ecomerciais.

 A inicialização desta fase é dada por requisições formais de clientes (umexemplo é uma carta convite solicitando um produto ou serviço). O planejamento

desta fase estabelece quem e quando será realizada cada atividade pertinente àconfecção de uma proposta técnica e/ou comercial. A execução de um projeto nafase de proposta é determinada pela execução de atividades como: delimitação doescopo do projeto, levantamento dos requisitos do produto ou serviço, estudo denovas tecnologias, cálculo de custos, elaboração de estimativas de tamanho e

esforço, análise dos riscos, etc. Os modelos para planejamento de projetos podemser utilizados na etapa de execução da fase de proposta. Dois exemplos destesmodelos podem ser vistos em Sanches [Sanches2001] e na [ISO9000-3:1997]. Afinalização da fase de proposta ocorre quando o cliente envia um pedido solicitando aexecução ou o cancelamento da proposta para o desenvolvimento de um produto ouserviço. A empresa também pode optar por cancelar uma proposta enviada para umcliente.

 A fase de execução se caracteriza pela realização de um escopo definido por um projeto, considerando os recursos da organização e um cronograma específico.

Nesta fase são realizadas comumente as atividades de engenharia do produto desoftware. Os principais artefatos gerados são: a especificação técnica, os artefatos deengenharia, o aceite do cliente e a comunicação ao cliente. A comunicação intensivacom os clientes pode ocorrer nesta fase devido a atrasos, revisão de cronogramas,revisões técnicas, inclusão de novos requisitos, entre outros.

 A inicialização da fase de execução é dada por uma autorização interna para aexecução do projeto. O planejamento prevê a construção de um plano de projeto que

38

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 47/101

 

PROGER: Processo de Gerência de Projetos de Software

envolve atividades como: decompor requisitos, estimar em detalhes o tamanho dosoftware, estimar recursos do projeto, elaborar cronograma e negociar compromissos. O modelo do ciclo de planejamento de projetos de software descritopela ISO9000-3 [ISO9000-3:1997] pode ser utilizado nesta etapa. Nesta etapa éprevista a confecção da estrutura de divisão de trabalho (WBS – Work Breakdown

Structure), ou seja, a divisão do trabalho total do projeto em fases e atividadesindependentes. O PMI guia a confecção de WBSs no trabalho [PMIWBS].

Nesta etapa também se define o modelo de ciclo de vida e a metodologia queserão utilizados no desenvolvimento do projeto. A etapa de execução determina arealização de atividades previstas no plano de projeto. A finalização da fase deexecução do modelo de ciclo de vida dos projetos se dá com a entrega do produto ouserviço ao cliente. A obtenção de um aceite do cliente (interno ou externo à empresa)determina o término da fase de execução. A empresa e/ou cliente também podecancelar um contrato e desta forma finalizar um projeto sem que tenha sido terminada

a sua execução.

 Após a execução do projeto, o período de  garantia estabelece um esforçotécnico, para a revisão de alguns problemas encontrados após o término do projeto.

 A duração deste período depende do acordo realizado com o cliente. Os artefatosdesta fase geralmente são os mesmos da fase de execução, só que dizem respeitoàs modificações e às correções do que já fora realizado e entregue ao cliente.

 A inicialização desta fase acontece quando a empresa obtém o aceite formal docliente no término da execução de um projeto. O  planejamento prevê o

estabelecimento de recursos que estarão disponíveis para atender o cliente na fasede garantia. Todavia, este estabelecimento prévio pode não existir. Na etapa deexecução são realizadas as atividades para adequação do produto ou serviço àssolicitações do cliente. A finalização da fase de garantia ocorre quando o prazodeterminado no contrato entre a empresa e o cliente findar.

No período de encerramento o projeto é dado como finalizado. Todo o trabalhoproposto foi concluído, aceito e garantido. Outros tipos de encerramentos podemocorrer, tais como, os decorrentes de cancelamento de contratos. A inicialização

desta fase ocorre quando o prazo de garantia do projeto findar ou quando um projeto

em prospecção, proposta ou execução for cancelado. Não há etapas deplanejamento, de execução e de finalização.

4.1.1 Controle e avaliação

Pontos de avaliação são utilizados para sincronizar as expectativas dosstakeholders através do ciclo de vida do projeto [Kerzner2001] [PMBOK2000]. Adefinição de alguns pontos de avaliação permite a observação de problemas na

39

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 48/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

execução do que fora planejado e possibilita uma ação corretiva antes do término doprojeto.

O ponto mais importante de avaliação de um projeto é um milestone, queusualmente é o evento em que o projeto passa de uma fase para outra. Os pontos de

avaliação menores (intrafases) são altamente dependentes do projeto e da culturaorganizacional [Royce1998] e são mais importantes de serem consideradosprincipalmente na fase de execução do modelo de ciclo de vida de projetospropostos. Nós aconselhamos que sejam considerados os pontos de avaliaçãodescritos no modelo de ciclo de vida do desenvolvimento adotados pelo projeto paraa fase de execução.

 A aplicação do modelo PDCA – Plan Do Check Act [Campos1992] em todas asfases do modelo de ciclo de vida também pode ser considerada. O ciclo PDCA decontrole (Figura 4.2) objetiva a prática do controle de processos e pode ser utilizado

para manter e melhorar as diretrizes de controle de um modelo de processo. Oestabelecimento de metas para cada fase é importante para que o processo estejaem constante melhoria. Os itens de controle podem considerar faixas de valorespadrão como, por exemplo: qualidade-padrão, custo-padrão, prazo-padrão,quantidade-padrão, entre outros.

FIGURA 4.2 Ciclo PDCA de controle de processos

 A ISO15504 [ISO15504:1-9:1998] e o CMM/CMMI [Paulk1993] [CMMI:2000]definem também indicadores de desempenho do processo que podem ser considerados para realização de avaliações para o modelo de ciclo de vida dos

P

(Plan)

D

(DO)

A

(Action)

C

(Check)

Definir as metas

Definir osmétodos que

permitirão atingir asmetas propostas

Educar etreinar 

Executar a tarefa(coletar dados)

Verificar osresultados da

tarefa executada

 Atuar corretivamente

40

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 49/101

 

PROGER: Processo de Gerência de Projetos de Software

projetos. O uso de checklist  para cada ponto de avaliação definido também ébastante útil.

4.2 STAKEHOLDERS

O PMBOK [PMBOK2000] define stakeholders como sendo os indivíduos ou asorganizações que estão ativamente envolvidos em um projeto. Nós estabelecemos,para efeito de simplificação, um conjunto mínimo de elementos para a empresa quepoderão estar envolvidos em um projeto. Estes elementos e suas funções estãoapresentados a seguir:

• diretor – responsável por estipular as metas e diretrizes da empresa;

• gerente comercial – responsável por manter a interface entre a empresa e ocliente. deve estar apto a perceber demandas de mercado e a estabelecer parcerias para construção de soluções mais completas para clientes. realizatambém renegociações de prazos e preços de projetos em execução;

• gerente de tecnologia – responsável por pesquisar e estabelecer astendências tecnológicas futuras da empresa. dá apoio ao desenvolvimentodos produtos/serviços e dissemina o conhecimento técnico da empresa;

• gerente de projetos – responsável pelo gerenciamento e acompanhamentode todos os projetos de software da empresa ou de uma área específica. fazalocação e planejamento dos recursos da empresa como um todo ou da áreade sua responsabilidade. revisa o planejamento feito pelo líder de projeto eacompanha o uso adequado de metodologias e padrões da empresa;

• gerente de processo e qualidade – estabelece metas, juntamente com adiretoria, visando à melhoria do processo de software e qualidade dosprodutos/serviços gerados pela empresa. é encarregado pela padronização eem auxiliar a gerência de projetos no acompanhamento dos projetos daempresa;

• líder de projeto – responsável por planejar e gerenciar a execução de umprojeto específico;

• técnico – neste grupo se encontra os desenvolvedores de forma geral, taiscomo: engenheiros de software, administradores de sistemas de workflow,analistas de sistemas, administradores da infra-estrutura, analistas de

negócio, arquitetos de dados, administradores de banco de dados, webdesigners, entre outros;

• cliente – organização ou setor da empresa que solicita a execução de umserviço e/ou produto de software;

• empresa sub-contratada – outra empresa a quem pode ser delegada aexecução de algumas atividades do projeto de software.

41

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 50/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

 A Figura 4.3 apresenta uma proposta de organograma para uma empresa desoftware, representando uma hierarquia entre os stakeholders. 

FIGURA 4.3 Organograma sugerido

4.3 ARTEFATOS

 Artefato pode ser definido como um conjunto de informações que é produzido,modificado ou usado por um processo. Nós estabelecemos um conjunto mínimo de

artefatos considerado críticos para o gerenciamento de projetos de software de umaempresa. Estes artefatos são: documentos de requisitos, propostas técnicas,propostas comerciais, relatórios de teste, atas de reunião, relatórios de visitastécnicas, planos de projeto, ordens de serviço e relatórios de aceite. A Figura 4.4apresenta estes artefatos e a influência existente entre eles.

Líder da Equipe 1

Gerente ComercialGerente de Tecnologia

 

Técnicos

Cliente

Empresa Subcontratada

Técnicos

Líder da Equipe n

Técnicos

Líder da Equipe 2

Gerente Projetos

DIRETOR

42

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 51/101

 

PROGER: Processo de Gerência de Projetos de Software

FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto

Os parágrafos seguintes descrevem os artefatos, suas características principaise os responsáveis por sua confecção. Ressaltamos que, o ProGer está focado maisem artefatos de gerenciamento do que em artefatos de engenharia.

 A Tabela 4.1 mostra os artefatos que podem ser gerados nas respectivas fasesdo modelo de ciclo de vida dos projetos descritos na seção 4.1.

TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dosprojetos

Fase ArtefatosProspecção Documentos de requisitos e atas de reunião.

Proposta Documentos de requisitos, propostas comerciais, propostas técnicas, atas dereunião.

Execução Documentos de requisitos, relatório de teste, relatórios de aceite, planos deprojeto, ordens de serviço e relatórios de visitas técnicas.

Garantia Relatórios de teste, atas de reuniões, ordens de serviço e relatórios de visitatécnica.

Encerramento Atas de reunião.

Nós recomendamos que as instâncias dos artefatos sejam armazenadas em

uma área comum, na pasta de seus respectivos projetos. Estabelecemos um padrãopara nomeação dos artefatos visando facilitar o acesso aos documentos. A Tabela4.2 mostra este padrão.

TABELA 4.2 Sugestão de padrão para nomeação dos artefatos

Artefato Padrão para Nomeação Exemplo

Documentos ‘DocumentoRequisitos’ + ‘_’ + Código_Projeto + ‘_’+ DocumentoRequisitos_DVX121-

43

Relatório de Teste

Documento RequisitosProposta Técnica

Proposta Comercial

Relatório de Aceite

Ata de Reunião

Ordem de Serviço

Relatório Visita

Técnica

Plano de

Projeto

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 52/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

de Requisitos Número_Versão 01_01

PropostasTécnica

‘PropostaTécnica’ + ‘_’ + Código_Projeto + ‘_’+Número_Versão

PropostaTécnica_DVX121-01_01

PropostaComercial

‘PropostaComercial’ + ‘_’ + Código_Projeto + ‘_’+Número_Versão

PropostaComercial_DVX121-01 _01

Planos deProjeto

‘PlanoProjeto’ + ‘_’ + Código_Projeto + ‘_’+Número_Versão

PlanoProjeto_DVX121-01_01

Relatório deTeste

‘RelatorioTeste’ + ‘_’ + Código_Projeto + ‘_’+ Data(ano-mes-dia) +’ _’ + [Número_Sequencial] 

RelatorioTeste_DVX121-01_2001-01-01_01

 Atas deReunião

‘AtaReuinião’ + ‘_’ + Código_Projeto + ‘_’+ Data(ano-mes-dia) +’ _’ + [Número_Sequencial] 

 AtaReunião_DVX121-01_2001-01-01_01

Relatórios deVisita Técnica

‘RelatórioTécnico’ + ‘_’ + Código_Projeto + Data(ano-mes-dia) +’ _’ + [Número_Sequencial] 

RelatórioTécnico_DVX121-01_2001-01-01_01

Relatórios de Aceite

‘Aceite’ + ‘_’ + Código_Projeto + ‘_’+Número_Aceite +’ _’ + [Número_Versão] 

 Aceite_DVX121-01_01_01

Ordens deServiço

´Ordem´+ ́ Código_Projeto + ́ _´+ NúmeroOrdem Ordem_DVX121-01_01

4.3.1 Documento de requisitos

Um requisito descreve uma condição ou aptidão que um produto de software ouserviço deve possuir para satisfazer um contrato ou uma requisição de um cliente daempresa. O documento de requisitos registra todos os requisitos funcionais e não-funcionais deste produto ou serviço.

Este artefato pode possuir diversas versões com níveis de refinamentodiferenciados 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 umasugestão de conteúdo para este artefato. O apêndice A deste módulo apresenta umtemplate para a confecção de um documento de requisitos.

O documento de requisitos pode ser confeccionado em projetos que seencontram em todas as fases, com exceção da fase de encerramento. O maiscomum é sua confecção nas fases de prospecção e proposta, com o refinamentosendo realizado na fase de execução. Este artefato pode ser feito por gerentes deprojeto, gerentes comerciais, líderes de projeto e técnicos.

44

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 53/101

 

PROGER: Processo de Gerência de Projetos de Software

Conteúdo do Documento de Requisitos

45

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 54/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

Fundação de Apoio ao Ensino, Pesquisa e Extensão - FAEPE....................................................................................2

Parceria..........................................................................................................145Reitor ............................................................................................................145Vice-Reitor.....................................................................................................145Diretor da Editora...........................................................................................145Pró-Reitor de Pós-Graduação.......................................................................145

Pró-Reitor Adjunto de Pós-Graduação “Lato Sensu”....................................145Coordenação do curso..................................................................................145Presidente do Conselho Deliberativo da FAEPE .........................................145Editoração .....................................................................................................145Impressão......................................................................................................145

Nenhuma parte desta publicação pode ser reproduzida,145

Introdução 71.1 Projeto e a Gerência de Projetos..........................................................................91.2 Motivação e Relevância da Gerência de Projetos..............................................101.3 As Dificuldades do Gerenciamento de Projetos de Software.............................111.4 Estrutura do Módulo............................................................................................12

Modelos, Padrões e Normas e a Gerência de PRojetos 142.1 Processos de Gerenciamento da ISO/IEC15504................................................142.2 PMBOK................................................................................................................18

2.2.1 Gerência de integração de projetos........................................................192.2.2 Gerência de escopo de projetos..............................................................202.2.3 Gerência de tempo de projetos...............................................................212.2.4 Gerência de custo de projetos.................................................................212.2.5 Gerência da qualidade de projetos.........................................................222.2.6 Gerência de recursos humanos de projetos...........................................22

2.2.7 Gerência de comunicação de projetos....................................................222.2.8 Gerência de risco de projetos..................................................................232.2.9 Gerência de aquisição de projetos..........................................................23

2.3 Modelagem do Sistema de Processos dE Empresa de Software......................242.4 Elementos essenciais para criar um processo de gerência de projetos.............252.5 Considerações.....................................................................................................27

Política Organizacional e Padrões ADotados para A definição do ProGer 303.1 pOLÍTICA oRGANIZACIONAL Considerada para o ProGer..............................30

3.1.1 Caracterização da empresa....................................................................303.1.2 Metas pretendidas com a gerência de projetos......................................32

3.2 Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer................32ProGER: Processo de Gerência de Projetos de Software 36

4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................364.1.1 Controle e avaliação................................................................................39

4.2 Stakeholders .......................................................................................................414.3 Artefatos .............................................................................................................42

4.3.1 Documento de requisitos.........................................................................444.3.2 Proposta técnica......................................................................................484.3.3 Proposta Comercial ................................................................................50

46

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 55/101

 

PROGER: Processo de Gerência de Projetos de Software

FIGURA 4.5 Sugestão de conteúdo para um documento de requisitos

47

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 56/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

4.3.2 Proposta técnica

Uma proposta técnica apresenta uma proposição de prestação de serviços paraum determinado cliente. Serve como instrumento para o acompanhamento do serviçoprestado ou a confecção de um produto. Este artefato pode ser confeccionado por 

qualquer elemento da empresa, dependendo da habilidade e dos conhecimentos queeste possui no escopo que está sendo abordado. Porém, sempre deve ser revisadapelo gerente de processo e qualidade e/ou gerente de projeto.

O documento de requisitos pode ser especificado dentro da proposta técnica ouestar como um anexo desta. A Figura 4.6 apresenta uma sugestão de conteúdo parauma proposta técnica. O apêndice A deste módulo apresenta um template para aconfecção de uma proposta técnica.

Conteúdo da Proposta Técnica

48

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 57/101

 

PROGER: Processo de Gerência de Projetos de Software

Parceria..........................................................................................................145Reitor ............................................................................................................145Vice-Reitor.....................................................................................................145Diretor da Editora...........................................................................................145Pró-Reitor de Pós-Graduação.......................................................................145Pró-Reitor Adjunto de Pós-Graduação “Lato Sensu”....................................145

Coordenação do curso..................................................................................145Presidente do Conselho Deliberativo da FAEPE .........................................145Editoração .....................................................................................................145Impressão......................................................................................................145

Nenhuma parte desta publicação pode ser reproduzida,145

Introdução 71.1 Projeto e a Gerência de Projetos..........................................................................91.2 Motivação e Relevância da Gerência de Projetos..............................................101.3 As Dificuldades do Gerenciamento de Projetos de Software.............................11

1.4 Estrutura do Módulo............................................................................................12Modelos, Padrões e Normas e a Gerência de PRojetos 142.1 Processos de Gerenciamento da ISO/IEC15504................................................142.2 PMBOK................................................................................................................18

2.2.1 Gerência de integração de projetos........................................................192.2.2 Gerência de escopo de projetos..............................................................202.2.3 Gerência de tempo de projetos...............................................................212.2.4 Gerência de custo de projetos.................................................................212.2.5 Gerência da qualidade de projetos.........................................................222.2.6 Gerência de recursos humanos de projetos...........................................222.2.7 Gerência de comunicação de projetos....................................................222.2.8 Gerência de risco de projetos..................................................................232.2.9 Gerência de aquisição de projetos..........................................................23

2.3 Modelagem do Sistema de Processos dE Empresa de Software......................242.4 Elementos essenciais para criar um processo de gerência de projetos.............252.5 Considerações.....................................................................................................27

Política Organizacional e Padrões ADotados para A definição do ProGer 303.1 pOLÍTICA oRGANIZACIONAL Considerada para o ProGer..............................30

3.1.1 Caracterização da empresa....................................................................303.1.2 Metas pretendidas com a gerência de projetos......................................32

3.2 Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer................32ProGER: Processo de Gerência de Projetos de Software 36

4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................364.1.1 Controle e avaliação................................................................................39

4.2 Stakeholders .......................................................................................................414.3 Artefatos .............................................................................................................42

4.3.1 Documento de requisitos.........................................................................444.3.2 Proposta técnica......................................................................................484.3.3 Proposta Comercial ................................................................................50

49

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 58/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

FIGURA 4.6 Sugestão de conteúdo para uma proposta técnica

4.3.3 Proposta Comercial

Este artefato apresenta uma proposta comercial de prestação de serviços paraum determinado cliente e deverá servir como o instrumento legal para oacompanhamento do serviço prestado. Os termos aqui estabelecidos foram definidosa partir das informações constantes na proposta técnica quando já conhecida e aceitapelas partes envolvidas. Deve contemplar acordos referentes a preço, pagamento,garantia e multas. A confecção de uma proposta comercial é de responsabilidade dosgerentes comerciais, porém deve ser aprovada pelo diretor.

 A Figura 4.7 sugere um conteúdo para uma proposta comercial. Um frameworkpara construção de uma proposta comercial pode ser visto no Apêndice A.

Conteúdo da Proposta Comercial

50

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 59/101

 

PROGER: Processo de Gerência de Projetos de Software

Parceria..........................................................................................................145Reitor ............................................................................................................145Vice-Reitor.....................................................................................................145Diretor da Editora...........................................................................................145Pró-Reitor de Pós-Graduação.......................................................................145Pró-Reitor Adjunto de Pós-Graduação “Lato Sensu”....................................145

Coordenação do curso..................................................................................145Presidente do Conselho Deliberativo da FAEPE .........................................145Editoração .....................................................................................................145Impressão......................................................................................................145

Nenhuma parte desta publicação pode ser reproduzida,145

Introdução 71.1 Projeto e a Gerência de Projetos..........................................................................91.2 Motivação e Relevância da Gerência de Projetos..............................................101.3 As Dificuldades do Gerenciamento de Projetos de Software.............................11

1.4 Estrutura do Módulo............................................................................................12Modelos, Padrões e Normas e a Gerência de PRojetos 142.1 Processos de Gerenciamento da ISO/IEC15504................................................142.2 PMBOK................................................................................................................18

2.2.1 Gerência de integração de projetos........................................................192.2.2 Gerência de escopo de projetos..............................................................202.2.3 Gerência de tempo de projetos...............................................................212.2.4 Gerência de custo de projetos.................................................................212.2.5 Gerência da qualidade de projetos.........................................................222.2.6 Gerência de recursos humanos de projetos...........................................222.2.7 Gerência de comunicação de projetos....................................................222.2.8 Gerência de risco de projetos..................................................................232.2.9 Gerência de aquisição de projetos..........................................................23

2.3 Modelagem do Sistema de Processos dE Empresa de Software......................242.4 Elementos essenciais para criar um processo de gerência de projetos.............252.5 Considerações.....................................................................................................27

Política Organizacional e Padrões ADotados para A definição do ProGer 303.1 pOLÍTICA oRGANIZACIONAL Considerada para o ProGer..............................30

3.1.1 Caracterização da empresa....................................................................303.1.2 Metas pretendidas com a gerência de projetos......................................32

3.2 Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer................32ProGER: Processo de Gerência de Projetos de Software 36

4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................364.1.1 Controle e avaliação................................................................................39

4.2 Stakeholders .......................................................................................................414.3 Artefatos .............................................................................................................42

4.3.1 Documento de requisitos.........................................................................444.3.2 Proposta técnica......................................................................................484.3.3 Proposta Comercial ................................................................................50

51

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 60/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

FIGURA 4.7 Conteúdo para uma proposta comercial

4.3.4 Plano de Projeto

Um plano de projeto é um documento formal e aprovado que é utilizado paragerenciar a execução de um projeto [PMBOK2000]. Um plano de projeto delimita oescopo da execução do projeto levando em conta as condicionantes (opções dedecisão) escolhidas pelo cliente e anteriormente aprovadas na proposta técnica ecomercial.

 A estrutura de divisão do trabalho (WBS – Work Breadkdown Structure ou EAP – Estrutura Analítica do Projeto) é o elemento central deste artefato, ou seja, a divisãodo trabalho total do projeto em etapas e atividades independentes. Além da WBS,este artefato também deve apresentar os padrões e técnicas adotadas, a metodologiae o modelo de ciclo de vida do desenvolvimento, os artefatos que serão utilizados egerados, as ferramentas necessárias, o cronograma de atividades com os recursosalocados, e os critérios para conclusão das atividades e etapas do projeto.

O plano de projeto serve de guia para o líder de projeto acompanhar oandamento dos trabalhos e são confeccionados por líderes de projeto com aprovaçãodo gerente de projeto e/ou gerente de processo e qualidade. A Figura 4.8 apresentauma sugestão de conteúdo para um plano de projeto. Um modelo de plano de projetopode ser visto no Apêndice A.

52

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 61/101

 

PROGER: Processo de Gerência de Projetos de Software

Conteúdo do Plano de Projeto

53

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 62/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

Parceria..........................................................................................................145Reitor ............................................................................................................145Vice-Reitor.....................................................................................................145Diretor da Editora...........................................................................................145Pró-Reitor de Pós-Graduação.......................................................................145Pró-Reitor Adjunto de Pós-Graduação “Lato Sensu”....................................145

Coordenação do curso..................................................................................145Presidente do Conselho Deliberativo da FAEPE .........................................145Editoração .....................................................................................................145Impressão......................................................................................................145

Nenhuma parte desta publicação pode ser reproduzida,145

Introdução 71.1 Projeto e a Gerência de Projetos..........................................................................91.2 Motivação e Relevância da Gerência de Projetos..............................................101.3 As Dificuldades do Gerenciamento de Projetos de Software.............................11

1.4 Estrutura do Módulo............................................................................................12Modelos, Padrões e Normas e a Gerência de PRojetos 142.1 Processos de Gerenciamento da ISO/IEC15504................................................142.2 PMBOK................................................................................................................18

2.2.1 Gerência de integração de projetos........................................................192.2.2 Gerência de escopo de projetos..............................................................202.2.3 Gerência de tempo de projetos...............................................................212.2.4 Gerência de custo de projetos.................................................................212.2.5 Gerência da qualidade de projetos.........................................................222.2.6 Gerência de recursos humanos de projetos...........................................222.2.7 Gerência de comunicação de projetos....................................................222.2.8 Gerência de risco de projetos..................................................................232.2.9 Gerência de aquisição de projetos..........................................................23

2.3 Modelagem do Sistema de Processos dE Empresa de Software......................242.4 Elementos essenciais para criar um processo de gerência de projetos.............252.5 Considerações.....................................................................................................27

Política Organizacional e Padrões ADotados para A definição do ProGer 303.1 pOLÍTICA oRGANIZACIONAL Considerada para o ProGer..............................30

3.1.1 Caracterização da empresa....................................................................303.1.2 Metas pretendidas com a gerência de projetos......................................32

3.2 Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer................32ProGER: Processo de Gerência de Projetos de Software 36

4.1 Modelo de Ciclo de Vida para Projetos de Software...........................................364.1.1 Controle e avaliação................................................................................39

4.2 Stakeholders .......................................................................................................414.3 Artefatos .............................................................................................................42

4.3.1 Documento de requisitos.........................................................................444.3.2 Proposta técnica......................................................................................484.3.3 Proposta Comercial ................................................................................50

54

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 63/101

 

PROGER: Processo de Gerência de Projetos de Software

FIGURA 4.8 Sugestão de conteúdo para um plano de projeto

4.3.5 Relatório de teste

Um relatório de teste tem por finalidade o registro dos testes realizados emconjunto com os clientes (validação dos requisitos do projeto). Serve de documentobase para a especificação de novos requisitos, e análise e previsão para a realizaçãode alterações no produto ou serviço de software. Deve possuir a concordância dosusuários que estão envolvidos no processo de teste.

É importante durante a confecção deste artefato que seja feita uma referênciaaos requisitos que estão sendo testados. Este artefato é confeccionado por técnicose/ou líderes de projeto e pode ser utilizado para validar um único ou um agrupamentode requisitos ao mesmo tempo. A Figura 4.9 apresenta um modelo para relatório decasos de teste.

FIGURA 4.9 Modelo de relatório de teste

4.3.6 Ata de reunião

55

RELATÓRIO DE TESTEPROJETO <NOME DO PROJETO>CLIENTE <NOME DO CLIENTE>

CONTRATO: <IDENTIFICADOR DO CONTRATO>

Nome do Projeto

Data do Teste

Repetição deste teste [ ]1o [ ]2o [ ]3o [ ]4o [ ]5o [ ]6o [ ]7o [ ]8o [ ]9o [ ]10o [ ]11o [ ]12o

Relato do Teste e Observações

Empresa <Empresa> <Cliente> <Cliente>Nome

Assinatura

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 64/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

 As atas de reunião devem registrar todas as reuniões internas e externas daempresa descrevendo os tópicos discutidos e as metas estabelecidas. As atas dereunião podem ser confeccionadas por qualquer pessoa da empresa e devem conter a rubrica e aceite de todos os participantes da reunião. A Figura 4.10 apresenta ummodelo para este artefato.

FIGURA 4.10 Modelo de ata de reunião

4.3.7 Relatório de visitas técnicas

Os relatórios de visitas técnicas têm por objetivo registrar uma visita ao cliente,solicitada para resolver um determinado problema ou para elicitar algumprocedimento novo. Estes relatórios geralmente são confeccionados por técnicos elíderes de projeto. A realização da manutenção que envolva uma visita no cliente éregistrada por este artefato. A Figura 4.11 apresenta um modelo de relatório de visitatécnica.

ATA DE REUNIÃOPROJETO <NOME DO PROJETO>CLIENTE <NOME DO CLIENTE>

CONTRATO: <IDENTIFICADOR DO CONTRATO>

Redator: <nome do redator da ata>Data/Hora Início: <hora início>Local: <local onde foi realizada a

reunião>Data/Hora Fim: <hora fim>1. OBJETIVO <objetivo da reunião>2. PARTICIPANTES<relacionar nomes, funções dos participantes>3.TÓPICOS DISCUTIDOS/DEFINIÇÕES<descrição do tópico><detalhamento da definição>4. PRÓXIMAS AÇÕES<detalhar a ação>Responsável: <nome do responsável >5. PRÓXIMA REUNIÃO<data da próxima reunião, se for o caso>6. OBSERVAÇÃO

Esta ata foi redigida por <Nome Redator/e-mail/fone>. Qualquer dúvida ou discordância, favor entrar em contato com o redator.

 

Rubricas

56

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 65/101

 

PROGER: Processo de Gerência de Projetos de Software

FIGURA 4.11 Modelo de relatório de visita técnica

4.3.8 Relatório de aceiteUm relatório de aceite tem por finalidade obter o aceite do cliente e avaliar o

quão satisfeito ele ficou com o produto ou serviço, e estabelecer metas para aresolução dos problemas encontrados. Nós definimos dois tipos de relatórios deaceite: parcial e final. A Figura 4.12 apresenta um modelo para este artefato.

O relatório de aceite parcial estabelece a finalização de uma etapa do projeto.Esta etapa pode ser prevista pela ocorrência de um milestone ou mesmo peloestabelecimento de entregas parciais do serviço ou produto. Um exemplo pode ser oaceite do documento de requisitos revisado e detalhado. O relatório de aceite final 

objetiva delimitar o evento que estabelece que o projeto entra na garantia.

57

RELATÓRIO VISITA TÉCNICANome do Projeto:Nome do Cliente:Identificador do Contrato:

Solicitante: Data Solicitação:

Local: Data Entrega Serviço:

Problema / Requisição

Solução

Observação

Empresa <Empresa> <Cliente> <Cliente>Nome

Assinatura

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 66/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

FIGURA 4.12 Modelo de relatório de aceite

Os relatórios de aceite utilizam o documento de requisitos como base eregistram a satisfação do cliente, a estratégia para resolução dos problemas

apontados pelo cliente e estabelecimento de novas metas para correção de não-conformidades. Um relatório de aceite pode ser confeccionado por um líder de projetoe/ou gerente de projeto. O apêndice A apresenta um template para este artefato.

RELATÓRIO DE ACEITE (FINAL/PARCIAL)Projeto: <Nome do Projeto> Cliente: <Nome Cliente> Contrato: <Número Contrato>

Responsável: <Líder ou gerente de projeto, responsável pelo aceite> Aceitação: <Número >

Revisor(es): <clientes/usuários envolvidos no aceite> Data: <Data da Aceite>

I . REQUISITOSREQUISITOFUNCIONAL

DESCRIÇÃO AVALIAçÃO 

<código dorequisito>

<descrição do requisito> <OK, não conforme, conforme com restrições>

...

...

REQUISITO NÃOFUNCIONAL DESCRIÇÃO AVALIAçÃO <código do requisito> <descrição do requisito> < OK, não conforme, conforme com restrições>

...

...

II . PRODUTOS ENTREGUESPRODUTO OBSERVAÇÃO AVALIAçÃO 

<nome doproduto>

<descrição da observação> < OK, não conforme, conforme com restrições>

...

...

III . NÃO-CONFORMIDADES

<Nesta seção devem ser relacionados os desvios identificados e "como e quando" serão tratados.>ITEM RESPONSÁVEL AÇÕES E PRAZOS

<descrição do item a ser tratado>

<nome do responsável> < como será solucionado, data>

...

...

IV . SATISFAÇÃO DO CLIENTE COM RELAÇÃO AO SERVIÇOITEM OBSERVAÇÃ

OAVALIAçÃO 

Qualidade do atendimento < observação> < excepcional ,bom, razoável,insuficiente, péssimo>Qualidade dos produtosentregues...

V . CONCLUSÃOρ Serviço Considerado Conformeρ Serviço Considerado Conforme com Restriçãoρ Serviço Considerado Não-Conforme

 

58

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 67/101

 

PROGER: Processo de Gerência de Projetos de Software

4.3.9 Ordem de Serviço

Uma ordem de serviço registra uma requisição formal de um cliente para arealização de um serviço em projetos que estão em execução ou já foram concluídos.

 A ordem de serviço é preenchida pelo cliente e entregue ao líder do projeto. Aliberação do serviço solicitado necessita do aval do gerente de projeto ou gerente deprocesso e qualidade para que possa ser realizado. A Figura 4.13 apresenta ummodelo para este artefato.

FIGURA 4.13 Modelo de uma ordem de serviço

4.4 FLUXOS DE TRABALHO

Os fluxos de trabalho (workflows) representam uma seqüência de atividades quesão executadas em um negócio para produzir um resultado de valor para algum ator do negócio. De forma mais específica, um fluxo de trabalho define as atividades que

59

ORDEM DE SERVIÇONome do Projeto:

Nome do Cliente:Identificador do Contrato:Solicitante: Data Solicitação:Local: Data Entrega Serviço:

Solicitação

Custo Associado

Observação

Empresa <Empresa> <Cliente> <Cliente>Nome

Assinatura

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 68/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

deverão ser realizadas, a interconexão entre estas atividades, os atores envolvidos eos produtos (artefatos, produtos de manufatura, comunicação, etc.) que serãogerados para satisfazer uma necessidade do negócio. A ordem da execução de umfluxo de trabalho pode ser serial, paralela e/ou condicional.

Os fluxos de trabalho podem ser descritos informalmente ou formalmente.Fluxos de trabalho formais são descritos através de linguagens apropriadas, as WDLs(Workflow Description Languages). Algumas destas linguagens são derivadas demodelos conceituais conhecidos na engenharia de software como statecharts

[Kappel1995]. Outras, todavia, usam suas próprias estruturas conceituais como em[Casati1995] e [Rouiller1998]. Nós optamos por descrever os fluxos utilizandoflowchart  descrito em [Kerzner2001], por ser mais simples e permitir que sejamdeclarados também os executores de cada atividade. A Figura 4.14 apresenta asprimitivas que o flowchart utiliza para descrever os fluxos de trabalho.

Elipses mostram materiais, informações ouações (entradas) que iniciam o fluxo ou paramostrar o resultado do término (saída) dofluxo

Um retângulo ou caixa é usado para mostrar uma tarefa ou atividade que deve ser executada no fluxo

Símbolo que mostra pontos no fluxo ondeuma questão está sendo realizada ou umadecisão é requerida

 A Um círculo com uma letra ou um númeroidentifica uma quebra no fluxo que écontinuada na mesma página ou em outrapágina

Setas mostram a direção do fluxo

FIGURA 4.14 Primitivas do flowchart

No ProGer estabelecemos três fluxos de trabalho para uma empresa depequeno ou médio porte: fluxo de captação de projetos, fluxo de execução deprojetos e fluxo avaliação de projetos. Estes fluxos especificam os procedimentos que

são utilizados ao longo do modelo de ciclo de vida dos projetos apresentado na seção4.1. O Apêndice B apresenta em detalhes os fluxos do ProGer. A seguir faremos umaapresentação sucinta destes fluxos.

4.4.1 Fluxo de captação de projetos

O fluxo de captação de projetos define os procedimentos e artefatos que devemser gerados pela empresa quando ocorre a identificação de uma demanda ou

60

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 69/101

 

PROGER: Processo de Gerência de Projetos de Software

solicitação de um serviço ou produto pelo cliente. Este fluxo termina quando umaproposta comercial é entregue ao cliente ou um produto, serviço ou protótipo de umademanda que foi visualizada é finalizado. Cancelamentos podem ocorrer por parte docliente ou da empresa. Este fluxo de trabalho é utilizado nas fases de prospecção eproposta do modelo de ciclo de vida para projetos de software.

 A Figura 4.15 apresenta um resumo do fluxo de captação de projetos. O fluxocompleto está definido no Apêndice B deste módulo.

FIGURA 4.15 Resumo do fluxo de captação de projetos

 A confecção de propostas técnicas, propostas comerciais e planos de projetonecessitam de estimativas de tempo e custo, necessárias para a realização doescopo proposto no projeto. Diversas técnicas de estimativas existem com o intuitode prever tamanho, esforço, prazo e custo para produtos e serviços de software, taiscomo [Trindade2000] [Braga1996] e [Boehm1981]. Muitas destas técnicas requeremuma grande variedade de fatores de entrada, incluindo dados históricos, medidas decomplexidade de sistemas, análise de equipes de desenvolvimento, algumasrestrições de projeto e estimativas do volume de código (o tamanho do projeto).

61

Confecção deplano deprojeto

Confecção eaprovação de

proposta técnica

Confecção eaprovação de

proposta comercial

Proposta comercial éentregue ao cliente

Término

Construção deprotótipo?

S

N

Levantamento de

requisitos

Confecção dodocumento de

requisitos

Início

Cliente solicita serviçoou uma devmanda é

visualizada

Execução dasatividades do

plano de projeto

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 70/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

Porém, para que as técnicas sejam efetivas a empresa deve encontrar as condiçõesapropriadas ao seu negócio [Sanches2001].

 As empresas de pequeno porte possuem de forma geral algumas limitações quedevem ser consideradas para a escolha da técnica a ser utilizada nas estimativas de

seus projetos de software, entre elas podem citar: recursos de pessoal limitado, altorodízio de pessoal, imaturidade metodológica, projetos executados sem planejamentodetalhado, requisitos realizados geralmente por apenas um elemento da empresa,plano de risco e plano de contingência não considerados e processo ad-hoc.

O trabalho de Sanches [Sanches2001] traz uma revisão bibliográfica dosmétodos e técnicas utilizadas na fase de elaboração de estimativas e nas demaisfases do processo de planejamento, bem como um levantamento preliminar dasferramentas disponíveis para apoio às tarefas. Porém também conclui que, osmétodos para as estimativas, planejamento e controle das atividades devem ser 

simples, rápidos, eficazes e apresentados em uma linguagem mais aderente aosnegócios empresariais. Nós também acreditamos que as empresas de pequeno portedevem utilizar técnicas simples para estimar produtos e serviços de software, porémestas técnicas devem estar formalizadas e entendidas pelos elementos da empresaenvolvidos no processo.

Uma técnica que pode ser utilizada para estimar está focada no conhecimento ecapacidade de estimar das pessoas. Desta forma, está apto a estimar qualquer pessoa da empresa, dando prioridade àquelas que possuírem mais experiência natecnologia que será empregada, maiores conhecimentos do escopo do produto e/ou

serviço, e conhecimentos da organização que solicitou a execução do projeto(cliente).

Sugere-se que esta estimativa seja realizada baseada nos requisitos que oprojeto deve satisfazer. Para cada requisito do produto, ou serviço detalhado nodocumento de requisitos, uma quantidade de esforço em horas deve ser estimada.Esta quantidade de horas deve considerar de preferência sempre um profissional denível médio. A Tabela 4.3, confeccionada através da observação de realizamos emprojetos em algumas empresas de pequeno porte, apresenta um exemplo de comoos níveis de profissionais podem ser considerados.

TABELA 4.3 Sugestão de categorização de níveis de profissionais para umaempresa de pequeno porte

Nível do Profissional Categoria de Profissionais

1 Gerentes especializados e consultores

2 Gerentes e técnicos masters

3 Líderes de projetos e técnicos seniores

4 Técnicos juniores

5 Técnicos trainees e estagiários

 

Projeto: Roteamento de CaminhõesRequisito: [RF001] Cadastramento de Rotas dos Caminhões Dresser na mineração deTamanduáTipo de atividade: Engenharia de softwareComplexidade :03Prioridade: essencialHoras previstas para realização: 24Nível de profissional considerado: 3

62

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 71/101

 

PROGER: Processo de Gerência de Projetos de Software

FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto

 A previsão em horas determina o esforço que será despendido para a execuçãodo requisito no projeto. Quando da confecção do plano de projeto, por exemplo,pode-se fazer uma estimativa mais precisa do tempo real que será gastoestabelecendo para cada requisito a ser realizado um profissional específico ou níveisde profissionais e quantidade necessária de profissionais.

 A estimativa de custo monetário para o projeto pode ser realizada baseando-sena quantidade de horas previstas para a realização de cada requisito do projeto e nocusto da hora do profissional considerado na estimativa. A estimativa de prazo doprojeto é feita através da distribuição da disponibilidade dos recursos humanos queexecutarão as atividades do projeto.

 A Tabela 4.4 trás um resumo de métricas que podem ser utilizadas no fluxo decaptação de projetos de software. Maiores detalhes e pontos de medição podem ser 

vistos no Apêndice B.

TABELA 4.4 Métricas sugeridas para o fluxo de captação de projetos

Métricas Sugeridas no Fluxo de Captação de ProjetosT1 = Tempo de atendimento à solicitação do cliente;

T2= Tempo gasto para a confecção de uma proposta técnica/comercial 

T3= Tempo gasto para a avaliação de uma demanda observada

T4= Tempo estimado para a realização do protótipo

T5= Tempo gasto para a construção de um protótipo

T6= Tempo gasto para correção das não-conformidades do protótipo

T7= Tempo gasto para a validação do protótipo

 HE = Horas estimadas para a realização de um requisito de um de projeto

THE (Total de horas estimadas para o projeto) = Somatório de todas as HE 

V = Valor do salário mês do profissional 

VH(Valor hora do profissional) = V / 170

 XE (percentual do esforço 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) = somatório de todos CE do projeto

63

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 72/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

4.4.2 Fluxo de execução de projetos

O fluxo de execução de projetos se inicia após a aprovação de uma propostacomercial ou liberação da diretoria para a execução de um projeto interno daempresa. O término deste fluxo se dá quando todo o escopo do projeto foi realizado.Exceções deste fluxo incluem: (1) a alteração do documento de requisitos após seudetalhamento, (2) cancelamento do projeto por parte da empresa ou do cliente e (3) ocliente não deu um aceite satisfatório implicando na necessidade de um novo planode projeto. Este fluxo de trabalho ocorre na fase de execução do modelo de ciclo devida para projetos de software. A Figura 4.17 apresenta um resumo do fluxo deexecução de projetos. O fluxo completo está definido no Apêndice B deste módulo.

64

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 73/101

 

PROGER: Processo de Gerência de Projetos de Software

FIGURA 4.17 Resumo do fluxo de execução de projeto

 Após a análise da proposta técnica e comercial, inicia-se no fluxo de execuçãode projetos a elaboração de um plano de projeto, que define a estrutura de divisãototal do trabalho do projeto em etapas e atividades independentes. Outros elementostambém são definidos antes de efetivamente iniciar os trabalhos do projeto, taiscomo: as técnicas, metodologias, ferramentas e o modelo de ciclo de vida dedesenvolvimento que serão adotados; artefatos que serão utilizados e gerados;riscos; cronograma de atividades; e critérios para conclusão das atividades e etapasdo projeto. O plano de projeto serve de guia para o líder de projeto acompanhar oandamento dos trabalhos e delimita o escopo da execução do projeto, levando emconta as condicionantes escolhidas pelo cliente e anteriormente aprovadas naproposta técnica e comercial.

65

Realizaçãodas atividades

de ajuste

Execução dasatividades do

plano de projeto

Obtenção doaceite do projeto

Produto/Serviço éentregue ao cliente

É necessárioajustes ? S

N

Confecção eaprovação do

plano de projeto

Planejamentodos ajustes

Início

 Análise da propostatécnica/comercial

aprovada

Realizaçãoalterações

plano de prProblemas/

novosrequisitos? S

N

Determinação daestratégia para resolução

dos problemas

Término

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 74/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

Uma atividade a ser realizada em um projeto é determinada por um requisitofuncional ou não-funcional a ser cumprido. Uma tarefa é uma ocorrência da execuçãodesta atividade. Sempre que uma tarefa for executada, o executor deve estimar opercentual de realização do requisito. Uma classe de tipo de atividade deve sempreser associada ao requisito durante a confecção do plano de projeto, como por 

exemplo: engenharia de software, capacitação pessoal e coordenação.

Nós propomos que quando uma tarefa for executada, o executor estabeleça quetipo de atividade realizou. No caso de engenharia de software, um tipo de atividadepoderia ser: levantamento de requisitos, análise, projeto, implementação e teste.Desta forma, o apontamento de uma tarefa para uma atividade (requisito) de umprojeto 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

suas respectivas taxas de realização são utilizados para obtenção de algumasmétricas. A taxa de realização, por exemplo, permite que os líderes de projetopossam visualizar o quanto o projeto evoluiu. O registro dos problemas encontradosem campo, durante o apontamento das horas, auxilia os líderes para a identificaçãode problemas e determinação de estratégias para a sua resolução. Nósrecomendamos, para empresas de pequeno porte, que o apontamento de horas sejafeito uma vez ao dia, de preferência no início do expediente.

O fluxo de execução de projetos é dado como finalizado após o cliente validar eaceitar o produto ou serviço de software que foi encomendado. Durante as atividadesde validação, algumas não-conformidades podem ser encontradas e a empresa deveestabelecer estratégias para a realização dos ajustes (que serão registradas nosdocumentos de aceite parcial e final).

Projeto: Roteamento de CaminhõesRequisito: [RF001] Cadastramento de Rotas dos Caminhões Dresser na mineração deTamanduáTipo de atividade: Engenharia de softwareSubclasse da atividade : ProjetoData da execução da atividade: 12/12/2001Total de horas gastas: 10 horasPercentual realizado do requisito: 10%Problemas encontrados: okObservações: “xxx xxxx xxxx “

66

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 75/101

 

PROGER: Processo de Gerência de Projetos de Software

 A Tabela 4.5 apresenta algumas métricas que podem ser utilizadas no fluxo deexecução de projetos para auxiliar o acompanhamento dos projetos e posterior análise do desempenho do projeto. Maiores detalhes e pontos de medição podem ser vistos no Apêndice B.

TABELA 4.5 Métricas sugeridas para o fluxo de execução de projetos

Métricas Sugeridas no Fluxo de Execução 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 obtenção do aceite do produto/serviço realizado

T12 = Tempo gasto para correção das não-conformidades do produto/serviço

T13 = Tempo gasto para a validação do produto/serviçoh = horas gastas para execução de uma tarefa de um requisito em um plano de projeto

(apontamento diário)

 x = percentual realizado do requisito (estimativa dada pelo executor ao término doapontamento de uma h)

 H = somatório de h do requisito em um plano de projeto (apontamento total – tempo gasto

 para realizar o requisito)

TH (Total de horas gastas para a execução de um plano de projeto) = Somatório de todas as

 H 

TX = (percentual esforço real já gasto para a realização do requisito do projeto) = H / TH *

100TTX (percentual de realização do projeto) = somatório de todas (HE / THE * x) * 100 do

 projeto

4.4.3 Fluxo de avaliação de projetos

O fluxo de avaliação de projetos estabelece atividades que comparam o que foiplanejado para ser executado e o que foi efetivamente realizado. A Figura 4.19apresenta um resumo do fluxo de avaliação de projetos. O fluxo completo estádefinido no Apêndice B deste módulo.

O fluxo de avaliação de projetos permite que a empresa possa ter subsídiospara tomar decisões de melhoria do processo de software. A análise do desempenhode um projeto de software depende das metas que a empresa pretende atingir com amelhoria de seu processo. Um exemplo de algumas análises que poderiam ser feitasinclui: análise da satisfação do cliente; desempenho das estimativas (esforço, prazo ecusto); análise das possíveis causas para os problemas encontrados em campo;

67

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 76/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

desempenho dos recursos humanos; verificação se o trabalho realizado foi dentro doescopo inicialmente pretendido; etc.

Introdução demelhoria no

processo

Identificação demelhorias para

o processo

 Análise dodesempenho do

projeto

S

N

Início

Melhoriasaprovadas?

Término

FIGURA 4.19 Resumo do fluxo de execução de projetos

 A análise do desempenho do projeto fornece subsídios para que melhoriaspossam ser identificadas para o processo de software. Um exemplo pode ser aanálise do desempenho das estimativas, que possibilita a determinação de quaisrecursos humanos estão mais aptos a estimar para que clientes. Isto possibilita que aempresa direcione estes elementos para a realização de planejamentos maisrealísticos de prazo e custo para o projeto.

 Após identificar as possíveis melhorias para o processo de software énecessário que estas melhorias sejam aprovadas antes de sua efetiva implantaçãona empresa. A aprovação ou não de uma melhoria para o processo depende das

metas pretendidas pela organização. A Tabela 4.6 apresenta algumas métricas que podem ser utilizadas no fluxo de

avaliação dos projetos. Maiores detalhes e pontos de medição podem ser vistos no Apêndice B.

68

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 77/101

 

PROGER: Processo de Gerência de Projetos de Software

TABELA 4.6 Métricas sugeridas para o fluxo de avaliação de projetos

Métricas Sugeridas no Fluxo de Avaliação de Projetos

T14 = Tempo gasto para analisar o desempenho do projeto

T15 = Tempo gasto para aprovar e implantar melhorias no processo através da análise 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 CONSIDERAÇÕES

Objetivamos com este capítulo apresentar um exemplo de processo de gerênciade projetos que pode ser utilizado em empresas de pequeno e médio porte. Oprocesso aqui apresentado já foi utilizado como base para a modelagem do processode gerência de projetos de algumas empresas de software. O experimento maissignificativo do uso deste processo está relatado em Rouiller [Rouiller2001], quedescreve o acompanhamento de 81 projetos de software em uma empresa depequeno porte. Este trabalho também apresenta um framework  conceitual para aconstrução de ferramentas para apoiarem a gerência de projetos.

 A Tabela 4.7 apresenta alguns procedimentos utilizados pelo ProGer que estão

relacionados às áreas de conhecimento definidas pelo PMBOK.

69

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 78/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

TABELA 4.7 Relação de alguns procedimentos do proger e as áreas deconhecimento do PMBOK.

Área doConhecimento

Procedimentos do ProGer 

Gerência deIntegração

desenvolvimento e acompanhamento do plano de projetocontrole da execução do plano de projetoresolução de problemas durante a execuçãocontrole das versões e mudanças dos artefatosreuniões periódicas para estabelecimentos de metas e de acordosuso dos fluxos de trabalhorevisão dos artefatos

Gerência deEscopo de Projetos

definição do escopo do projeto através documento de requisitosaprovação do documento de requisitos pelo clienterevisão da especificação do documento de requisitosuso do modelo de ciclo de vida e seus artefatos associadosuso dos artefatos ordem de serviço e relatório de teste para identificar novos

requisitos

refinamento dos requisitos antes de dar início às atividades do projeto

Gerência deTempo

desenvolvimento e acompanhamento do plano de projetodefinição da rastreabilidade entre os requisitosestimativa da duração das atividades dos requisitos do projetoapontamento de esforço gasto para desenvolver as atividadesacompanhamento periódico da evolução do projeto

Gerência de Custodesenvolvimento e acompanhamento do plano de projetoestimativa de custos para cada atividade do projeto baseada no esforçoapontamento de esforço gasto para desenvolver as atividadesanálise dos dados históricos de outros projetos

Gerência da

Qualidade

determinação de metas de qualidade a serem atingidasavaliação periódica do projeto, baseado nas metas de qualidade desejadaavaliação da satisfação do cliente através do relatório de aceite

registro e análise dos problemas na execução dos projetosdesenvolvimento e acompanhamento do plano de projetorealização de estimativas e avaliação do desempenho dos projetosuso do ciclo PDCA

Gerência deRecursos Humanos

controle da disponibilidade dos recursosregistro das funções e responsabilidade de cada recursouso dos fluxos de trabalhodesenvolvimento e acompanhamento do plano de projetoidentificação das habilidades dos recursos humanosacompanhamento e análise do desempenho dos recursos humanosdefinição de milestones e r euniões periódicas

Gerência de

Comunicação

uso dos fluxos de trabalhoreuniões periódicas

disseminação do conhecimento adquirido pelos recursos humanos da empresadesenvolvimento e acompanhamento do plano de projeto

Gerência de Riscoidentificação dos riscos do projeto e estabelecimento de planos de contingênciadesenvolvimento e acompanhamento do plano de projeto

Gerência de Aquisição

desenvolvimento da proposta comercialdesenvolvimento do documento de requisitos

70

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 79/101

 

PROGER: Processo de Gerência de Projetos de Software 71

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 80/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

 

EXERCÍCIOS DE FIXAÇÃO:1.Considerando as metas que a empresa de software pretendia alcançar com aimplantação de um processo de gerência de projetos (identificada no capítulo 3 destemódulo), quais delas você acredita ser possível alcançar considerando o ProGer?Identifique em que pontos do ProGer você pode obter informações para poder ter subsídios para efetuar a melhoria pretendida (Discuta isso no fórum virtual). Lembrandoque as metas pretendidas são:

• Melhoria da satisfação do cliente;

• Melhoria da qualidade dos produtos gerados;

• Melhoria da qualidade do processo;

• Melhoria do gerenciamento dos recursos humanos;

• Melhoria da comunicação interna e externa da empresa;

• Melhoria do desempenho das estimativas de esforço, custo e prazo;

• Melhoria do estabelecimento das metas organizacionais;

• Melhoria na identificação dos riscos.2.Leia o estudo de caso da utilização 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 práticas básicas do modelo CMMI que o ProGer satisfaz? (o modelo CMMI está no material complementar). Crie uma tabela com estecomparativo, inclua sugestões de melhorias em artefatos e fluxos para tornar o ProGer aderente ao CMMI e apresente suas justificativas. (Pode ser utilizada a ISO15504também para este exercício).4.Se a sua empresa desejasse implantar um processo de gerência de projetos, de queforma você o faria? (apenas para meditar).

72

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 81/101

 

5FERRAMENTAS PARA APOIOAUTOMATIZADO AO PROGER

 Além de outros fatores, realizar o gerenciamento de projetos sem automaçãoimpossibilita a obtenção de algumas métricas e informações gerenciais de forma mais

eficiente, além de exigir grande intervenção humana. Contudo, os ambientes degerenciamento de projetos disponíveis no mercado não são específicos parasoftware, dificultando o processo.

 A engenharia de processo tem se esforçado no sentido de definir modelos epadrões para a construção de um efetivo ambiente para o processo de software.Exemplos podem ser vistos em [Cromer1999] [Gates1997] [Machado1999] e[Maidantchik1999]. O reconhecimento da importância dos processos e o crescimentoda cultura de processo têm levado as empresas à criação de ambientes de softwaremais eficientes, um exemplo é o PSEEs - Process-Centered Software Engineering 

Environment . Os PSEEs integram tanto os requisitos do produto, que são o foco daengenharia de software, como os requisitos do processo, que são o foco dogerenciamento do projeto e da engenharia de processo.

 Apesar de reconhecer a importância do processo de software e sua naturezadinâmica, os PSEEs são ambientes ainda complexos e de difícil utilização [Reis2000].Muitos problemas desta abordagem ainda não estão bem resolvidos, como osmecanismos para integração. No conceito mais amplo de PSEEs ainda inexistemferramentas disponíveis para uso efetivo pelas empresas. De forma geral são maiscomuns os gerenciadores de processos, que são uma camada dos PSEEs. Todavia,

estes gerenciadores desconsideram alguns elementos importantes no gerenciamentode projetos tais como: o acompanhamento do plano de projeto, o controle daexecução dos projetos, o registro dos problemas encontrados em campo, o registrodas estimativas e o apontamento do esforço. O trabalho de Reis [Reis2000] faz umaretrospectiva e análise dos PSEEs.

Outra abordagem que pode ser utilizada para gerenciamento de projetos é oWFMSs - Workflow Management Systems.  O WFMSs são sistemas que foram

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 82/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

originalmente construídos para a indústria manufatureira e para utilização emprocessos de negócio. Desta forma, não consideram a dinamicidade do processo desoftware. Os WFMSs também trabalham com o conceito da instanciação de umprocesso pré-definido, e cada processo de software é único. É possível tomar comobase processos padrões de software, mas não instanciá-los como é feito na

manufatura. Reis [Reis2000] estabelece que “existe pouca diferença entre PSEEs eprodutos workflow  (fluxo de trabalho), com exceção que produtos de workflowprovêem suporte mais direto a processos organizacionais”. Nós concordamos comesta colocação. Flexibilizar e simplificar o PSEEs e WFMSs seria uma tarefanecessária para a construção de ambientes que pudessem realizar o gerenciamentodos projetos nas empresas, principalmente no que se refere à obtenção de métricaspara introdução de melhorias em curto prazo.

 As ferramentas para CSCW-Computer-supported Cooperative Work exploram ouso do computador para facilitar e garantir o trabalho colaborativo entre as pessoas.

 As ferramentas de CSCW podem ser utilizadas também com o intuito de gerenciar projetos. Contudo, uma ferramenta de CSCW é “frouxa” e não permite oestabelecimento das responsabilidades e interdependência entre as atividades aserem realizadas em um plano de projeto de software. Elas impossibilitam umcontrole mais efetivo da execução se desconsiderarmos a confecção de um aplicativoespecífico projetado sobre esta plataforma.

 Algumas ferramentas para gerenciamento de projetos podem ser encontradasno mercado, contudo não são específicas para software. Melo [Melo2000] apresentaalguma destas ferramentas, descrevendo suas características, funcionalidades e

seus pontos fortes e fracos. Todavia estas ferramentas, em sua maioria, possibilitamsomente o registro da estrutura da divisão do trabalho do projeto, tornando oacompanhamento do projeto de software precário. A confecção dos planos estádesatrelada dos processos da empresa impossibilitando manter a integridade com oselementos do processo de software. A dinamicidade da execução de um projeto desoftware também dificulta o acompanhamento do projeto utilizando estes tipos deferramentas, que propõem a criação de novas versões do documento original.Comparar o que foi planejado com o executado é uma atividade que somente podeser realizada manualmente. Além disso, a maioria destas ferramentas não permite o

apontamento do esforço durante a execução das atividades do projeto e o controle deacesso é geralmente precário, baseado em acesso ao documento e não à atividadedo projeto.

O trabalho de Moura [Moura2000] relaciona algumas ferramentas que podemser utilizadas para a gestão de projetos de software.

66

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 83/101

 

Ferramentas para Apoio Automatizado ao ProGer 

Nas próximas seções apresentaremos um exemplo de conjunto de ferramentasque já foi adotada em conjunto com o ProGer, que serve como sugestão para apoiar o processo definido no capítulo 4.

5.1 FERRAMENTAS UTILIZADAS EM CONJUNTO COM O PROGER

5.1.1 Microsoft Word

Editor de textos, utilizado para a elaboração dos seguintes documentos:

• proposta técnica;

• proposta comercial;

• documentos de requisitos;

• status report;

• matriz de rastreabilidade;• pauta de reunião;

• cronograma de entrega;

• plano de iterações;

• plano de gerência de configuração;

• relatórios em geral.

O Word também é utilizado em alguns outros documentos intermediários aoscitados acima, como por exemplo documentos de informações sobre requisitos de

produtos ou serviços de software, avaliações iniciais de prospecções ou propostas,motivos de cancelamento de propostas etc.

O MS Word pode ser substituído por um outro editor de texto open source comoo Open Office Writer (http://www.openoffice.org/product/writer.html).

5.1.2 Microsoft Project

Ferramenta proprietária 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 eprojetos, delimitar a disponibilidade de recursos, definir prazos para atividades, etc.

Utilizado para gerar os seguintes documentos:

• cronograma de entrega;

• wbs (estrutura analítica do projeto).

67

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 84/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

O MS Project pode ser substituído por outra ferramenta open source paragerenciamento de projetos, como o dotProject (http://www.dotproject.net/).

5.1.3 Microsoft excel

Ferramenta proprietária da empresa Microsoft.Planilha eletrônica utilizada para elaboração de tabelas e/ou gráficos que podem

ser utilizados em conjunto com o MSWord na elaboração dos seguintes documentos:

• documentos de requisitos;

• status report;

• matriz de rastreabilidade;

• time sheet;

• relatório de controle dos requisitos: implementado, testado;

• relatório de controle de bugs: corrigido, testado, atualizado;• cronograma de entrega.

O MS Excel pode também ser substituído por uma alternativa open source comoo Open Office Calc (http://www.openoffice.org/product/calc.html).

5.1.4 Mantis

O Mantis é um issue tracker  open source.

Dentre os inúmeros usos do Mantis podemos citar o de reportar e gerenciar 

mudanças. Utilizada, entre outras, para elaboração dos seguintes documentos:• status report;

• documento de requisitos (quando se trata de requisitos adicionais, ourequisitos que ainda não estão bem definidos pelo cliente);

• relatório de controle de bugs.

Mais informações a respeito das funcionalidades da ferramenta podem ser encontradas no seguinte endereço: http://www.mantisbt.org/ .

Existem inúmeras outras opções 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/ ).

68

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 85/101

 

Ferramentas para Apoio Automatizado ao ProGer 

5.1.5 FreeVCS

Ferramenta freeware.

Ferramenta de controle de versões de arquivos, importantíssima para gerênciade configuração.

Pode ser utilizada como ferramenta de apoio para praticamente todos osartefatos e documentos de um projeto.

Mais informações a respeito das funcionalidades da ferramenta podem ser encontradas no seguinte endereço: http://www.thensle.de/

Existem opções open source para realizar o controle de versão como o popular Subversion (http://subversion.tigris.org/).

5.1.6 Microsoft outlook

Ferramenta proprietária da empresa Microsoft.

Ferramenta de envio e recebimento de e-mails, utilizado como ferramenta deapoio para elaboração e refinamento dos seguintes documentos:

• proposta técnica;

• proposta comercial;

• documentos de requisitos;

• relatório de controle de bugs.

Mais informações a respeito de preços, licenças e funcionalidades daferramenta podem ser encontradas no seguinte endereço:http://www.microsoft.com/outlook/ .

Uma alternativa open source é o Thunderbird (http://www.mozilla.com/en-US/thunderbird/).

5.1.7 Microsoft Windows Live Messenger 

Ferramenta utilizada para fazer reuniões e vídeo conferências, inclusive.

Essa ferramenta síncrona permite que o gerente tire dúvidas com um cliente queesteja fisicamente longe e a qualquer momento que o mesmo esteja conectado.Também pode ser utilizada como apoio à elaboração e refinamento dos seguintesdocumentos, entre outros:

• proposta técnica;

• proposta comercial;

• documentos de requisitos;

69

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 86/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

• relatório de controle de bugs.

Mais informações a respeito de licenças e funcionalidades da ferramenta podemser encontradas no seguinte endereço: http://get.live.com/messenger/overview

5.1.8 Base de acompanhamento de projetos

 A ferramenta, específica para gerenciamento de projetos, intitulada “Base de Acompanhamento de Projetos”, foi construída tendo como base o ProjectSpace6 

[Rouiller2001] e considera as particularidades do ProGer. Esta ferramenta foiconstruída na plataforma Lotus-Notes, que é um ambiente adequado para trabalhocooperativo e que envolve muita colaboração humana.

 A Figura 5.1 mostra uma visão do cadastramento de projetos. A notificação aogerente de processo e qualidade e ao diretor é feita automaticamente quando umnovo projeto é criado.

Cada projeto inicia-se em uma fase específica, baseada no modelo de ciclo devida de projetos descritos pelo ProGer. Para cada fase são associados os recursosque serão utilizados e quem será o responsável pelo projeto. A Base de

 Acompanhamento de Projetos permite a notificação aos executores e a convocaçãode reuniões. Lembrando que, um projeto pode ser iniciado em qualquer fase, comexceção do encerramento. A Figura 5.2 apresenta uma visão do cadastramento dafase do projeto.

6 O ProjectSpace é um framework conceitual que pode ser utilizado para a construção de ferramentas

para gerenciamento de projetos de software e foi concebido considerando os padrões da engenharia de processo e do gerenciamento de projetos.

70

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 87/101

 

Ferramentas para Apoio Automatizado ao ProGer 

 

FIGURA 5.1 Visão do cadastramento de projetos

FIGURA 5.2 Visão do cadastramento de fases do projeto

71

 

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 88/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

 Após a criação de um projeto em uma determinada fase macro-atividades7 sãocriadas pelo líder de projeto. O gerente de projeto é notificado da criação de todas asmacro-atividades, assim como os executores. Para uma macro-atividade pode ser atribuído um ou mais executores. O líder de projeto deve fazer uma previsão doesforço em tempo que será gasto para a realização da macro-atividade, além de

determinar a sua complexidade. A Figura 5.3 mostra uma visão do cadastramento deuma macro-atividade.

 FIGURA 5.3 Visão do cadastramento de macro-atividades

Posteriormente, os executores registram os tempos gastos (apontamento dehoras) nas macro-atividades, relacionando o tipo de atividade realizada. O executor faz uma estimativa da realização da macro-atividade, neste momento. Problemasencontrados em campo são notificados ao líder de projeto, neste momento. A Figura5.4 mostra uma visão do apontamento de horas nas macro-atividades.

7 As macro-atividades representam os requisitos funcionais e não-funcionais do produto ou serviço desoftware e possuem uma subclasse de atividade associada.

 

72

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 89/101

 

Ferramentas para Apoio Automatizado ao ProGer 

 

FIGURA 5.4 Visão do apontamento de horas nas macro-atividades

Informações gerenciais também podem ser obtidas através de relatóriossolicitados pela gerência e diretoria. A Figura 5.5 apresenta uma visão dos projetospor fase e cliente, apresentando os requisitos dos projetos e as respectivas taxas de

realização. Uma visão do esforço gasto em horas nos projetos é dada pela Figura5.6.

73

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 90/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

 

FIGURA 5.5 Visão de projetos por fase e cliente

 

FIGURA 5.6 Visão das horas gastas nos projetos

 A Figura 5.7 apresenta uma visão mostrando as horas apontadas por executor em projetos na Base de Acompanhamento de Projetos. A Figura 5.8 mostra a visãodiária do trabalho do executor.

74

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 91/101

 

Ferramentas para Apoio Automatizado ao ProGer 

FIGURA 5.7 Uma visão das horas gastas por colaborador 

 

FIGURA 5.8 Visão diária do trabalho do executor 

75

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 92/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

EXERCÍCIOS DE FIXAÇÃO:1. Você julga importante a utilização de ferramentas específicas de gerência de projetos? Por 

que quase toda organização de software geralmente constrói uma ferramenta proprietária

(como a Base de Acompanhamento de Projetos) quando inicia a automatização do

processo de gerenciamento? Compartilhe sua opinião no fórum virtual.

2. Forneça sugestões 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 gerência de

projetos de software? Você já as utilizou? Compartilhe seu conhecimento no fórum virtual.

76

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 93/101

 

6CONCLUSÃO

Este módulo apresentou conceitos básicos da gerência de projetos de software,enfatizando sua relevância e dificuldade de implantação nas empresas. Abordamostambém, no capítulo 2, alguns modelos para a construção de um processo paragerência de projetos. Os capítulos seguintes apresentaram um exemplo de processode gerência de projetos de software. A seguir realizaremos algumas considerações.

 As dificuldades de se implantar um processo para gerenciamento de projetosem empresas de software estão, principalmente, na falta de cultura em qualidade queas organizações possuem (principalmente as de pequeno e médio porte). O altorodízio de pessoal e o constante deslocamento de recursos humanos para suprir ademanda de um outro projeto, também, dificulta o bom desempenho de um processode gerenciamento de projetos de software. Realizar o gerenciamento dos projetossem a automação de alguns procedimentos do processo é uma tarefa muito árdua, e

porque não dizer, que quase inviabiliza a obtenção de dados para a melhoria doprocesso. Infelizmente, poucas ferramentas são apropriadas ao gerenciamento deprojetos de software.

 Apesar de sua relevância, temos observado que o gerenciamento de projetosnas empresas de software ainda é realizado geralmente de forma ad-hoc , causandoinúmeros prejuízos à organização, inclusive financeiros. Contudo, existe uma fortetendência ao surgimento de novos trabalhos nesta área. Isso pode ser observadoatravés dos processos incluídos nos padrões e normas para SPA/SPI e em estudos epublicações realizados nos últimos anos.

 Acreditamos que a comunidade de software deva, em breve, considerar mais asexperiências adquiridas e apresentadas pelo PMI-Project Management Institute. Issoinclui a realização de certificação para seus gerentes de projeto, assim como jáocorre com linguagens e tecnologia, garantindo uma melhor qualidade dos projetosque executam. Notamos também uma tendência dos adquirentes de produtos eserviços de software em exigirem gerentes de projetos certificados pelo PMI, para

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 94/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

terem mais garantia de que a execução de seus projetos estará de acordo com aespecificação pretendida nos contratos.

Na construção de um processo para gerência de projetos, os padrões e normaspara SPA/SPI se mostram eficientes, contudo, não são suficientes. O PMBOK

possibilita um melhor entendimento e uma ampliação mais eficaz dos conhecimentosda área de gerenciamento de projetos para a área de software.

Esperamos que este módulo tenha contribuído para elucidar a relevância dogerenciamento de projetos nas empresas de software e também possibilitado aoaluno mecanismos para que este possa se aprofundar no tema.

 

78

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 95/101

 

7REFERÊNCIAS BIBLIOGRÁFICAS

[Bellouquim1999] Belouquim, A. CMM em Pequenas Organizações: Seria Mesmo

Possível? Developers Magazine, Janeiro, 1999.

[Boehm1981] Hoehm. B. Software Engineering Economics. Eglewood Cliffs, Prentice-Hall Inc. 1981.

[Boehm1988] Boehm, B.  A Spiral Model for Software Development and 

Enhancement , Computer, vol. 21, n. 5, maio 1988.

[Braga1996] Braga, A. Análise de Pontos por Função. Rio de Janeiro: Infobook, 1996.

[Campos1992] Campos, V. F. TQC:Controle da Qualidade Total , Fundação ChristianoOtooni, 7a. edição 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 -OOEF’95, Gold Coast, Austrália, 1995.

[CMMI:2000] CMMI Model Componentes Derived from CMMI – SE/SW , Version 1.0Technical 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.

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 96/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

[Dorling1993] Dorling, A. Software Process Improvement and Capability 

Determination, Software Quality Journal, vol2, N. 4,1993.

[Fernandes1989] Fernandes, Aguinaldo Aragon & Kugler, J. L. C. Gerência 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 . SpecialReport 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 WesleyLongman 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 , versão PDAM 3, novembro2000.

[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.

80

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 97/101

 

Referências Bibliográficas

[Jones1999] Jones, C. Software Project Management in the 21st Century . AmericanProgrammer, 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: Europe´s assessment method , IEEESoftware, 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 , IEEESoftware, julho/agosto 2000.

[Machado1999] Machado, L. F. D. C. Modelo para Definição de Processos de

Software na Estação Taba, dissertação de mestrado, COPPE/UFRJ, 1999, Rio deJaneiro, RJ.

[Machado2001] Machado, C. A. & Burnett, R. C. Gerência de Projetos na Engenharia

de Software em Relação as Práticas do PMBOK . XII CITS - Conferência Internacionalde 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.

81

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 98/101

 

EDITORA – UFLA / FAEPE – Gerência de Projetos de Software

[Melo2000] Melo, E. F. & Moura, H. P. WebManager: uma ferramenta paraplanejamento e gerenciamento de projetos de software, trabalho de graduação,Centro de Informática, 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 EngineeringInstitute, 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 MellonUniversity, Software Engineering Institute, Addison-Wesley Longman Inc, 1997.

[Philippe1998] Philippe, K. The Rational Unified Process: an Introduction. Addison-Wesley Object Technology Series, 1998.

[PMBOK2000] A Guide to the Proiject Management Body of Knowledge, PMI-ProjectManagement Institute, Newtown Square, Pennsylvania, USA, 2000.

[PMIWBS] PMI Project Management Standards Program.http://www.pmi.org/standards/.

[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 Execução de Processos de Software, Exame de Qualificação deDoutorado, PPGC-UFRGS, 2000.

[Rouiller2001] Rouiller A. C. Gerenciamento de Projetos de Software para Empresasde Pequeno Porte. Doutorado em Ciência da Computação pela UFPE. Engenharia deSoftware e Qualidade de Software, 2001.

[Royce1998] Royce, W. Software Project Management: a unified framework . AddisonWesley Longman, 1998, USA.

[Sanches2001] Sanches, R. & Júnior, W. T. Proposta de um Modelo de Processo de

Planejamento de Projeto de Software para Melhoria de Gerenciamento de Projetos .XII CITS - Conferência Internacional de Tecnologia de Software, junho, 2001.

82

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 99/101

 

Referências Bibliográficas

[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. São Paulo:Makron Books do Brasil Ltda, 1999.

83

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 100/101

 

8APÊNDICE A

Neste apêndice serão apresentados os seguintes artefatos do ProGer:

1. Proposta Comercial2. Proposta Técnica

3. Documento de Requisitos

4. Plano de Projeto

5. Relatório de Aceite

6. Relatório de Teste

7. Ordem de Serviço

8. Funcionalidades

5/16/2018 Apostila Gerencia de Projetos de Software - slidepdf.com

http://slidepdf.com/reader/full/apostila-gerencia-de-projetos-de-software 101/101

 

9APÊNDICE B

Neste apêndice serão apresentados os seguintes encartes, anexos ao módulo“Gerência de Projetos de Software”:

1. Fluxo de captação de projetos de produtos e serviços de software;

2. Fluxo de execução e avaliação de projetos de produtos e serviços de

software.