apostila gerencia de projetos de software
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.