Gerência de Projetos de Software

Transcrição

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

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

3 Parceria Universidade Federal de Lavras - UFLA Fundação de Apoio ao Ensino, Pesquisa e Extensão - FAEPE Reitor Antônio Nazareno Guimarães Mendes Vice-Reitor Elias Tadeu Fialho Diretor da Editora Marco Antônio Rezende Alvarenga Pró-Reitor de Pós-Graduação Joel 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 Oliveira Presidente do Conselho Deliberativo da FAEPE Luiz Antônio Lima Editoração Centro de Editoração Quality Group Impressão Gráfica Universitária/UFLA Ficha Catalográfica Preparada pela Divisão de Processos Técnicos da Biblioteca Central da UFLA Rouiller, Ana Cristina Gerência de Projetos de Software/Ana Cristina Rouiller. Lavras: UFLA/FAEPE, p.:il. (Curso de Pós-graduação Lato Sensu (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. Nenhuma parte desta publicação pode ser reproduzida, por qualquer meio, sem a prévia autorização da FAEPE.

4

5 SUMÁRIO Fundação de Apoio ao Ensino, Pesquisa e Extensão - FAEPE...2 Parceria Reitor Vice-Reitor Diretor da Editora Pró-Reitor de Pós-Graduação Pró-Reitor Adjunto de Pós-Graduação Lato Sensu Coordenação do curso Presidente do Conselho Deliberativo da FAEPE Editoração Impressão Nenhuma parte desta publicação pode ser reproduzida, 145 Introdução Projeto e a Gerência de Projetos Motivação e Relevância da Gerência de Projetos As Dificuldades do Gerenciamento de Projetos de Software Estrutura do Módulo...12 Modelos, Padrões e Normas e a Gerência de PRojetos Processos de Gerenciamento da ISO/IEC PMBOK Gerência de integração de projetos Gerência de escopo de projetos Gerência de tempo de projetos Gerência de custo de projetos Gerência da qualidade de projetos Gerência de recursos humanos de projetos Gerência de comunicação de projetos Gerência de risco de projetos Gerência de aquisição de projetos Modelagem do Sistema de Processos de Empresa de Software Elementos essenciais para criar um processo de gerência de projetos Considerações...27 Política Organizacional e Padrões ADotados para A definição do ProGer política organizacional Considerada para o ProGer Caracterização da empresa Metas pretendidas com a gerência de projetos Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer...32 ProGER: Processo de Gerência de Projetos de Software Modelo de Ciclo de Vida para Projetos de Software Controle e avaliação...39

6 4.2 Stakeholders Artefatos Documento de requisitos Proposta técnica Proposta Comercial Plano de Projeto Relatório de teste...55 Nome 55 Assinatura Ata de reunião Relatório de visitas técnicas...56 RELATÓRIO VISITA TÉCNICA...58 Solicitante: 58 Data Solicitação: 58 Local: 58 Data Entrega Serviço: 58 Problema / Requisição...58 Nome 58 Assinatura Relatório de aceite Ordem de Serviço...60 ORDEM DE SERVIÇO...60 Solicitante: 60 Data Solicitação: 60 Local: 60 Data Entrega Serviço: 60 Nome 60 Assinatura Fluxos de Trabalho Fluxo de captação de projetos Fluxo de execução de projetos Fluxo de avaliação de projetos Considerações...71 Ferramentas para APOIO Automatizado ao ProGer Ferramentas Utilizadas em Conjunto com o ProGer Microsoft Word Microsoft Project Microsoft excel Mantis FreeVCS Microsoft outlook Microsoft Windows Live Messenger Base de acompanhamento de projetos...70 CONCLUSÃO 77 REFERÊNCIAS BIBLIOGRÁFICAS 79 APÊNDICE A 86 APÊNDICE B 1

7

8

9 LISTA DE FIGURAS FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto 8 FIGURA 2.1 As dimensões do modelo de referência da ISO/IEC FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19 FIGURA 2.3 Áreas do gerenciamento de projetos do PMBOK 20 FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de software FIGURA 2.5 Modelo para criação de processo de gerenciamento de projetos de software 26 FIGURA 3.1 Porte das empresas, segundo a força de trabalho efetiva 31 FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37 FIGURA 4.2 Ciclo PDCA de controle de processos 40 FIGURA 4.3 Organograma sugerido 42 FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43 TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos projetos 43 TABELA 4.2 Sugestão de padrão para nomeação dos artefatos 43 FIGURA 4.5 Sugestão de conteúdo para um documento de requisitos 47 FIGURA 4.6 Sugestão de conteúdo para uma proposta técnica 50 FIGURA 4.7 Conteúdo para uma proposta comercial 52 FIGURA 4.8 Sugestão de conteúdo para um plano de projeto 55 FIGURA 4.9 Modelo de relatório de teste 55 FIGURA 4.10 Modelo de ata de reunião 56 FIGURA 4.11 Modelo de relatório de visita técnica 57 FIGURA 4.12 Modelo de relatório de aceite 58 FIGURA 4.13 Modelo de uma ordem de serviço 59 FIGURA 4.14 Primitivas do flowchart 60 FIGURA 4.15 Resumo do fluxo de captação de projetos 61 TABELA 4.3 Sugestão de categorização de níveis de profissionais para uma empresa de pequeno porte 62 FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto 63 TABELA 4.4 Métricas sugeridas para o fluxo de captação de projetos 63 FIGURA 4.17 Resumo do fluxo de execução de projeto 65 FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto 66 TABELA 4.5 Métricas sugeridas para o fluxo de execução de projetos 67 FIGURA 4.19 Resumo do fluxo de execução de projetos 68 TABELA 4.6 Métricas sugeridas para o fluxo de avaliação de projetos 69 TABELA 4.7 Relação de alguns procedimentos do proger e as áreas de conhecimento do PMBOK. 70 FIGURA 5.1 Visão do cadastramento de projetos 71 FIGURA 5.2 Visão do cadastramento de fases do projeto 71

10 FIGURA 5.3 Visão do cadastramento de macro-atividades FIGURA 5.4 Visão do apontamento de horas nas macro-atividades FIGURA 5.5 Visão de projetos por fase e cliente FIGURA 5.6 Visão das horas gastas nos projetos 74 FIGURA 5.7 Uma visão das horas gastas por colaborador FIGURA 5.8 Visão diária do trabalho do executor 75

11 LISTA DE TABELAS FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto 8 FIGURA 2.1 As dimensões do modelo de referência da ISO/IEC FIGURA 2.2 Processos do gerenciamento de projetos do PMBOK 19 FIGURA 2.3 Áreas do gerenciamento de projetos do PMBOK 20 FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de software FIGURA 2.5 Modelo para criação de processo de gerenciamento de projetos de software 26 FIGURA 3.1 Porte das empresas, segundo a força de trabalho efetiva 31 FIGURA 4.1 Modelo de ciclo de vida de projetos de software 37 FIGURA 4.2 Ciclo PDCA de controle de processos 40 FIGURA 4.3 Organograma sugerido 42 FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto 43 TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos projetos 43 TABELA 4.2 Sugestão de padrão para nomeação dos artefatos 43 FIGURA 4.5 Sugestão de conteúdo para um documento de requisitos 47 FIGURA 4.6 Sugestão de conteúdo para uma proposta técnica 50 FIGURA 4.7 Conteúdo para uma proposta comercial 52 FIGURA 4.8 Sugestão de conteúdo para um plano de projeto 55 FIGURA 4.9 Modelo de relatório de teste 55 FIGURA 4.10 Modelo de ata de reunião 56 FIGURA 4.11 Modelo de relatório de visita técnica 57 FIGURA 4.12 Modelo de relatório de aceite 58 FIGURA 4.13 Modelo de uma ordem de serviço 59 FIGURA 4.14 Primitivas do flowchart 60 FIGURA 4.15 Resumo do fluxo de captação de projetos 61 TABELA 4.3 Sugestão de categorização de níveis de profissionais para uma empresa de pequeno porte 62 FIGURA 4.16 Exemplo de estimativa de tempo para um requisito de um projeto 63 TABELA 4.4 Métricas sugeridas para o fluxo de captação de projetos 63 FIGURA 4.17 Resumo do fluxo de execução de projeto 65 FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto 66 TABELA 4.5 Métricas sugeridas para o fluxo de execução de projetos 67 FIGURA 4.19 Resumo do fluxo de execução de projetos 68 TABELA 4.6 Métricas sugeridas para o fluxo de avaliação de projetos 69 TABELA 4.7 Relação de alguns procedimentos do proger e as áreas de conhecimento do PMBOK. 70 FIGURA 5.1 Visão do cadastramento de projetos 71 FIGURA 5.2 Visão do cadastramento de fases do projeto 71 FIGURA 5.3 Visão do cadastramento de macro-atividades 72

12 8 EDITORA UFLA / FAEPE Gerência de Projetos de Software 73 FIGURA 5.4 Visão do apontamento de horas nas macro-atividades FIGURA 5.5 Visão de projetos por fase e cliente FIGURA 5.6 Visão das horas gastas nos projetos 74 FIGURA 5.7 Uma visão das horas gastas por colaborador FIGURA 5.8 Visão diária do trabalho do executor 75

13 1 INTRODUÇÃO A Engenharia de Software tem por finalidade auxiliar na construção de software da 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 quanto tempo e esforço serão necessários para produzir um sistema de software que satisfaça às necessidades (requisitos) dos clientes/usuários. Sistemas de software são geralmente entregues muito tempo depois do que fora planejado; Programas de baixa qualidade programas de software não executam o que o cliente deseja, conseqüência, talvez, da pressa para se entregar o produto. Os requisitos originais podem não ter sido, completamente, especificados ou podem apresentar contradições e isto pode ser descoberto muito tarde durante o processo de desenvolvimento; Alto custo para manutenção a manutenção pode ser corretiva, quando ocorrem enganos (erros, falhas) no sistema já entregue, ou evolutiva quando novas características são adicionadas ao sistema de software. Ambas são caras quando o sistema original foi construído sem uma arquitetura clara e visí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 de confianç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êm adotado metodologias de desenvolvimento de software. Todavia, os paradigmas metodológicos para desenvolvimento de software têm sido considerados somente em termos de um método de análise/projeto/implementação, isto é, um conjunto de conceitos, técnicas e notações. Esta visão elimina os aspectos tecnológicos,

14 8 EDITORA UFLA / FAEPE Gerência de Projetos de Software contextuais e organizacionais que potencialmente existem dentro de um processo de software. De forma geral, podemos dividir as funções de uma empresa de software em trê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 do processo, pela engenharia do produto e pelo gerenciamento de projeto. O relacionamento entre estes grupos é mostrado na Figura 1.1 [Garg1996]. A engenharia do produto é encarregada do desenvolvimento e manutenção dos produtos e serviços de software. A principal figura da engenharia do produto é a metodologia de desenvolvimento, que engloba uma linguagem de representação, um modelo de ciclo de vida e um conjunto de técnicas. Os ambientes tradicionais de desenvolvimento de software têm se preocupado essencialmente com a engenharia do 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 uma organização que desenvolve software e torná-la mais produtiva e adequada às exigências do mercado. Experiências passadas Requisitos do processo Engenharia do processo Modelo do processo Requisitos do projeto Requisitos do produto Gerenciamento de projeto Processo de desenvolvimento Produto de software Engenharia do produto FIGURA 1.1 Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto

15 Introdução 9 A engenharia de processo tem como metas a definição e a manutenção dos processos de uma organização. Ela deve ser capaz de facilitar a definição, a análise e a simulação de um processo, assim como estar apta a implantá-lo, avaliá-lo, medilo e melhorá-lo. A engenharia de processo pode ser vista como uma extensão da funçã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 das organizações que desenvolvem software sente muita dificuldade em entender, definir e gerenciar estes processos. As empresas de software devem buscar os seus próprios ambientes para existirem e operarem. Abordagens da indústria manufatureira, por exemplo, não têm demonstrado serem adequadas à indústria de software. O gerenciamento de projeto objetiva assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessários para um projeto produzir 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, tais como: dinamicidade do processo, grande número de variáveis envolvidas, exigência de adaptabilidade ao ambiente de desenvolvimento e constantes alterações no que foi planejado. Estes fatores dificultam o trabalho das equipes de desenvolvimento na medição do desempenho dos projetos, na verificação de pontos falhos, no registro de problemas, 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 o objetivo de criar um produto, serviço ou resultado único [PMBOK2000] A temporalidade de um projeto significa que um projeto deve possuir um inicio e um fim definido e estabelecido. O final pode ser quando os objetivos do projeto forem alcançados, ou quando ele é cancelado (por se chegar a uma conclusão de que os objetivos não poderão ser alcançados ou pela mudança das necessidades). A meta da gerência de projetos é conseguir exceder as necessidades e expectativas dos stakeholders 1 [PMBOK2000]. Todavia, satisfazer ou exceder estas necessidades envolve um balanceamento entre as várias demandas concorrentes em relaçã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].

16 10 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 demonstraram que o gerenciamento de projeto é a causa mais evidente das falhas na execução e entrega de produtos e serviços de software. O SEI-Software Engineering Institute constatou, já em 1993, que o principal problema que aflige as organizações de software é gerencial e preconizou que: as organizações precisam vencer o seu buraco negro que é o seu estilo de gerenciar de maneira informal, sem métodos e sem 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 pobre gerenciamento por parte do desenvolvedor e adquirente, deixando claro que o problema não é de desempenho técnico. O estudo realizado pelo Standish Group [Standish1995], chamado de relatório do Chaos, focou a indústria de software comercial. Esse estudo identificou que: as empresas dos Estados Unidos gastaram $81 bilhões em projetos de software que foram cancelados em 1995; 31% dos projetos estudados foram cancelados antes de estarem concluídos; 53% dos projetos de software que foram concluídos excederam mais 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ções de 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 o sucesso 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 aos desastres do software são falhas específicas no domínio do gerenciamento de projeto, e os três dos outros dez fatores restantes estão indiretamente associados às praticas de gerenciamento pobre. Walker [Walker1997] conclui que: o desenvolvimento de software ainda é imprevisível; somente 10% dos projetos de software são entregues com sucesso dentro das estimativas de orçamento e custo; a disciplina de gerência é mais um discriminador de sucesso ou falha do que são os avanços tecnológicos e a quantidade de softwares jogados fora, e que tem necessidade de re-trabalho, são um indicativo de processo imaturo.

17 Introdução 11 Muitas pesquisas enfatizam que o gerenciamento é a principal causa do sucesso ou fracasso dos projetos de software. Apesar disso, o gerenciamento de projetos de software ainda é pouco abordado e praticado nas empresas de software [Machado2001]. Jones [Jones1999] destaca que a ausência de um processo de gerenciamento apropriado, aliado às estimativas deficientes de custo e de tempo, é umas das principais causas das falhas dos projetos de software. Os principais padrões e normas para SPA/SPI (Software Process Assessment/ Software Process Improvement) 2 têm colocado o gerenciamento de projetos como um dos 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 tem se mostrado complexo demais, além de causar uma sobrecarga de trabalho significativa. Segundo Belloquin [Belloquin1999], estes padrões e normas definem prá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ácil compreensão pode ser de grande valor, fornecendo uma orientação aos gerentes de projeto e dificultando a ocorrência de falhas graves de gerenciamento por falta de experiê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 de inconveniê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 atual cultura das organizações de software o planejamento, quando ocorre, é feito de forma superficial [Weber1999] [Sanches2001]. Muitos projetos de software são realizados sem um planejamento de como a idéia modelada pelo levantamento de requisitos e necessidades 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 o quanto 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 incorretos e, portanto, estarem desperdiçando tempo. 2 Exemplos de SPA/SPI são: CMM, CMMI, BootStrap, ISO9000, ISO/IEC15504, ISO12207, entre outros.

18 12 EDITORA UFLA / FAEPE Gerência de Projetos de Software Boas estimativas de custo, esforço e prazo de software requerem um processo ordenado que defina a utilização de métricas de software, método e ferramenta de estimativa. As empresas de software, de forma geral, não detêm conhecimentos e recursos para isso [Vigder1994]. Estimar, medir e controlar um projeto de software são tarefas difíceis, pois o desenvolvimento de software é uma atividade criativa e intelectual, com muitas variáveis envolvidas (como metodologias, modelos de ciclo de vida, técnicas, ferramentas, tecnologias, recursos e atividades diversas). Os gerentes inexperientes tentam cumprir prazos dando a máxima velocidade na fase inicial e estão despreparados para os momentos de impasse, quando os ajustes são inevitáveis. A dinamicidade do processo de software dificulta também o gerenciamento efetivo de projetos de software, devido às alterações constantes nos planos de projetos, redistribuição de atividades, inclusão/exclusão de atividades, adaptação de cronogramas, realocação de recursos, novos acordos com os clientes, entregas intermediárias não previstas etc. Um projeto de software também deve adaptar-se ao ambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades do pessoal ou equipe. Outros fatores ainda agravam os problemas de gerenciamento de projetos de software em empresas de pequeno e médio porte, tais como: inexistência de um processo definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura em processos, pouco treinamento em engenharia de software, imaturidade metodoló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 cinco capítulos e dois apêndices. O capítulo 2 aborda padrões, normas e modelos que definem boas práticas para a gerência de projetos de software. Este capítulo também propõe um modelo com elementos essenciais para a construção de um processo de gerê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 de projetos 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 é um processo que pode ser aplicado para empresas de pequeno e médio porte. Estes três capítulos objetivam mostrar ao aluno um exemplo de como um processo de gerência de projetos de software que pode ser utilizado para melhorar o desempenho de uma empresa. Por fim, o capítulo 6 realiza uma conclusão geral sobre os temas abordados neste módulo.

19 Introdução 13 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 que você já observou e queira compartilhar conosco? 3. No início do capítulo foi apresentada uma pesquisa realizada por Gibbs em Esta pesquisa demonstrou que a Engenharia de Software, em diversos aspectos, ficou estagnada desde 1960, quando foi publicado o texto The Software Crisis. Os mesmos problemas apresentados em 1960 eram os de Você acha que existe algum fator histórico que mereça destaque para esta estagnação da Engenharia de Software? Você acredita que este quadro 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 de melhoria com a gerência de projetos? Por que as metodologias de desenvolvimento estão sendo 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 alguns problemas da indústria de software dos Estados Unidos. Em 2001 foi realizada uma pesquisa similar. Você conhece esta pesquisa? Os indicadores continuam os mesmos? Como se comportou a indústria de software dos Estados Unidos de 1995 para 2001? Compartilhe esta pesquisa 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 do PMBOK). 8. Você concorda com a afirmação da seção 1.1 que diz que um projeto deve ter característica TEMPORAL? (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 no PMBOK).

20 14 EDITORA UFLA / FAEPE Gerência de Projetos de Software

21

22 2 MODELOS, PADRÕES E NORMAS E A GERÊNCIA DE PROJETOS Os estudos realizados na década de 1990 sobre gerenciamento de projetos de software deixaram evidente que as práticas de gerenciamento de projetos devem ser melhoradas para que os projetos de software tenham sucesso. Dada esta preocupação, muitos modelos e normas para SPA/SPI evoluíram, principalmente com a 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 na ISO/IEC15504 no decorrer de sua confecção. Contudo, Machado [Machado2001] demonstrou recentemente que apesar das pesquisas evidenciarem que o problema da indústria de software é mais gerencial do que 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 e normas para SPA/SPI com as contidas no PMBOK Project Management Body Knowledge 3 [PMBOK2000], concluiu-se que os requisitos de gerenciamento de projeto não estão representados devidamente nos modelos [Machado2001]. O gerenciamento de projeto de software tem sido priorizado há pouco tempo pelas organizações que definem padrões e normas para software. A ISO/IEC15504 é quem aborda o gerenciamento de projetos de software de forma mais completa [Wang1999]. Ela estabelece um conjunto de práticas básicas que devem ser seguidas para o sucesso do gerenciamento de projetos de software. Desta forma, optamos por destacar neste capítulo os processos de gerenciamento de projetos proposto pela ISO/IEC Este capítulo também apresentará as áreas de conhecimento do PMBOK. 2.1 PROCESSOS DE GERENCIAMENTO DA ISO/IEC 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.

23 Modelos, Padrões e Normas e a Gerência de Projetos 15 Em 1993, um grupo de trabalho conjunto da ISO/IEC-International Organization for Standardization/International Electrotechnical Commission estabeleceu um projeto denominado SPICE-Software Process Improvement and Capability Evaluation [Dorling1993], que objetivava chegar a um consenso entre os diversos métodos de avaliaçã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ão internacional emergente que estabelece um framework para construção de processos de avaliação e melhoria do processo de software. Este framework pode ser utilizado pelas empresas envolvidas em planejar, gerenciar, monitorar, controlar e melhorar a aquisiçã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ística genérica permite que possa ser utilizada em conjunto com uma variedade de métodos, de técnicas e de ferramentas. Nove documentos compõem a ISO/IEC Alguns têm caráter normativo (como a ISO/IEC , ISO/IEC e ISO/IEC ) e outros possuem caráter informativo (como a ISO/IEC , ISO/IEC , ISO/IEC , ISO/ IEC , ISO/IEC e ISO/IEC ). A ISO/IEC define um modelo de referência de processo e um modelo de capacitação do processo (Figura 2.1) que pode compor a base para a definição e avaliação de um processo de software. Este modelo de referência possui uma abordagem bidimensional. Categoria CUS Processos do Ciclo de Vida ENG SUP MAN ORG... Processo X 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 Dimensão de Processo Dimensão de Capacidade 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 dos processos necessários em uma empresa, assim como sua adequação à

24 16 EDITORA UFLA / FAEPE Gerência de Projetos de Software ISO/IEC A segunda dimensão, similar ao CMM, tem por objetivo determinar a capacidade do processo da empresa, avaliando-o através de um conjunto de atributos preestabelecidos. Os atributos de processo estão agrupados nos níveis de capacidade e podem ser aplicados em todos os processos descritos na organização para determinar a maturidade do processo. Cinco grupos de processos são definidos pela ISO/IEC : 1. Fornecedor-Cliente (CUS-Custormer-Supplier): são os processos que de alguma forma impactam diretamente o cliente, dentre eles o suporte para desenvolvimento e transações de software para o cliente, fornecimento de operações corretas e uso do produto de software ou serviço; 2. Engenharia (ENG-Engineering): esta categoria agrupa os processos que especificam, implementam e mantém o produto de software, sua relação com o sistema e a documentação do cliente; 3. Suporte (SUP-Support): são processos que podem ser empregados em algum 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áticas gerenciais que podem ser utilizadas por alguém que gerencia algum tipo de projeto ou processo dentro do ciclo de vida do software; 5. Organização (ORG-Organization): são processos que estabelecem as finalidades dos processos de desenvolvimento e da organização, do produto e dos recursos que, quando utilizados por projetos na organização, realizarão as metas do negócio. A categoria de processo MAN (Management process category) é quem estabelece os processos de gerenciamento para a empresa, que estão subdivididos em quatro grupos: MAN.1 Processo de gerenciamento organiza, monitora e controla o início e o desempenho de qualquer processo ou função dentro da empresa, alcançando as metas 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ço de acordo com seus requisitos; MAN.3 Gerenciamento da qualidade monitora a qualidade dos produtos e serviç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.

25 Modelos, Padrões e Normas e a Gerência de Projetos 17 Apesar dos quatros agrupamentos estarem envolvidos no gerenciamento de projetos, vamos descrever apenas o grupo MAN.2, que está subdividido em 12 prá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 atingidas considerando os recursos disponíveis e as restrições; MAN.2.BP2 Determina a estratégia de desenvolvimento, avaliando as opções disponíveis para alcançar as metas do projeto, estabelecendo os riscos e as oportunidades 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 alcance das 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 a seqüência das tarefas, levando em conta os recursos requeridos e a estratégia adotada; MAN.2.BP6 Identifica os requisitos da infra-estrutura, ou seja, os elementos do ambiente e os recursos humanos necessários para suportar a estratégia e a execução do projeto; MAN.2.BP7 Estabelece o cronograma do projeto, baseado na estrutura de divisão do trabalho, estimativas realizadas e elementos da infra-estrutura considerados; MAN.2.BP8 Aloca responsabilidades, identificando os indivíduos específicos e os 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 com outros 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á sendo executado; MAN.2.BP12 Corrige os desvios quando os objetivos do projeto não estão sendo alcançados.

26 18 EDITORA UFLA / FAEPE Gerência de Projetos de Software Os processos de gerenciamento começam a ser necessários na ISO/IEC15504 somente a partir do nível 2 de capacidade e estão distribuídos conforme mostra a Tabela 2.1. TABELA 2.1 Distribuição dos processos de gerenciamento nos níveis de capacidade da ISO/IEC15504 Níveis de Capacidade 1. Processo Executado Categorias de Processo de Gerenciamento 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 PMBOK O PMI Project Management Institute é uma associação de profissionais de gerenciamento de projetos que existe desde Esta associação criou em 1986 a primeira versão do PMBOK Project Management Body of Knowledge 4. O PMBOK é um guia que descreve a somatória de conhecimento e as melhores práticas dentro da profissão de gerenciamento de projetos. É um material genérico que serve para todas as áreas de conhecimento, ou seja, tanto para construção de um edifício como para a produçã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 as vá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 possui diversos outros documentos e relatos que são bastante relevantes para a gerência de projetos. Para se aprofundar no assunto, você pode consultar o material complementar do ambiente virtual ou visitar o site

27 Modelos, Padrões e Normas e a Gerência de Projetos 19 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 do projeto. Os processos de planejamento definem e refinam os objetivos do projeto, Processos de Inicialização Processos de Planejamento Processos de controle Processos de execução Processos de finalização selecionando as melhores alternativas para realizá-lo. Os processos de execução coordenam pessoas e outros recursos para a realização do projeto, baseando-se no planejamento. Os processos de controle monitoram e medem o progresso do que está sendo executado, com o intuito de tomar 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 se referem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentro destas áreas de conhecimento os cinco grupos de processos acima descritos podem ocorrer. A figura 2.3 mostras as 9 áreas de conhecimento do PMBOK. A seguir descreveremos os processos de cada área de conhecimento do PMBOK. Todos os processos descritos, das áreas abaixo, interagem uns com os outros e também com os processos das demais áreas de conhecimento. Cada processo pode envolver esforço de um ou mais indivíduos ou grupos de indivíduos, dependendo das necessidades do projeto. Cada processo, geralmente, ocorre pelo menos uma vez em cada fase do projeto Gerência de integração de projetos

28 20 EDITORA UFLA / FAEPE Gerência de Projetos de Software A gerência de integração engloba os processos necessários para garantir que os vários elementos de um projeto sejam propriamente coordenados. Objetiva realizar as negociações dos conflitos entre objetivos e alternativas do projeto com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a 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 outros processos de planejamento, construindo um documento coerente e consistente; execução do plano do projeto - levar a cabo o projeto através da realizaçã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 Gerência de Projeto Gerência de Integração Gerência de Escopo Gerência de Tempo Gerência de Custo Gerência de Qualidade Gerência de Recursos Humanos Gerência de Comunicação Gerência de Risco Gerência de Aquisição 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 fundamental compreende definir e controlar o que está ou não incluído no projeto. Essa área de processo incluiu os seguintes processos principais:

29 Modelos, Padrões e Normas e a Gerência de Projetos 21 iniciação - comprometer a organização a iniciar a próxima fase do projeto; planejamento do escopo - desenvolver uma declaração escrita do escopo como base para decisões futuras do projeto; detalhamento do escopo - subdividir os principais subprodutos do projeto em 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 do projeto Gerência de tempo de projetos A gerência de tempo do projeto objetiva garantir o término do projeto no tempo certo. Consiste da definição, ordenação e estimativa de duração das atividades e de elaboração e controle de cronogramas. Essa área incluiu os seguintes processos principais: definição das atividades - identificar as atividades específicas que devem ser realizadas para produzir os diversos subprodutos do projeto; seqüenciamento das atividades - identificar e documentar as relações de dependência entre as atividades; estimativa da duração das atividades - estimar a quantidade de períodos de 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 Gerência de custo de projetos A gerência de custo tem por objetivo garantir que o projeto seja executado dentro 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 para executar as atividades do projeto; estimativa dos custos - desenvolver uma estimativa dos custos dos recursos necessários à implementação das atividades do projeto;

30 22 EDITORA UFLA / FAEPE Gerência de Projetos de Software orçamento dos custos - alocar as estimativas de custos globais aos itens individuais de trabalho; controle dos custos - controlar as mudanças no orçamento do projeto Gerência da qualidade de projetos A gerência da qualidade objetiva garantir que o projeto satisfará as exigências para as quais foi contratado. Consiste no planejamento, garantia e controle de qualidade. Essa área de processo incluiu os seguintes processos principais: planejamento da qualidade - identificar quais padrões de qualidade são relevantes para o projeto e determinar a forma de satisfazê-los; garantia da qualidade - avaliar periodicamente o desempenho geral do projeto, 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 relevantes e identificar as formas para eliminar as causas de desempenhos insatisfatórios Gerência de recursos humanos de projetos A gerência de recursos humanos objetiva garantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste no planejamento organizacional, alocação de pessoal e definição de equipe. Essa área de processo incluiu os seguintes processos principais: planejamento organizacional - identificar, documentar e designar as funções, responsabilidades e relacionamentos de reporte dentro do projeto; montagem da equipe - conseguir que os recursos humanos necessários sejam designados e alocados ao projeto; desenvolvimento da equipe - desenvolver habilidades individuais e do grupo para aumentar o desempenho do projeto Gerência de comunicação de projetos A gerência de comunicação tem por objetivo principal garantir a geração adequada e apropriada, coleta, disseminação, armazenamento e disponibilização da informação. Essa área de processo incluiu os seguintes processos principais:

31 Modelos, Padrões e Normas e a Gerência de Projetos 23 planejamento das comunicações - determinar as informações e comunicações necessárias para os interessados: quem necessita de qual informação, quando necessitarão dela e como isso será fornecido; distribuição das informações - disponibilizar as informações necessárias para os interessados do projeto da maneira conveniente; relato de desempenho - coletar e disseminar as informações de desempenho. Inclui relatórios de situação, medição de progresso e previsões; encerramento administrativo - gerar, reunir e disseminar informações para formalizar a conclusão de uma fase ou de todo o projeto 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 de afetar o projeto e documentar as características de cada um; quantificação dos riscos - avaliar os riscos, suas interações e possíveis conseqüências; desenvolvimento das respostas aos riscos - definir as melhorias necessárias para o aproveitamento de oportunidades e respostas às ameaças; controle das respostas aos riscos - responder às mudanças nos riscos no decorrer do projeto Gerência de aquisição de projetos A gerência de aquisição tem por objetivo principal obter bens e serviços externos à organização executora. Consistem na seleção de fornecedores, planejamento de aquisição, planejamento de solicitação, solicitação de propostas e administraçã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 e identificar os fornecedores potenciais; obtenção de propostas - obter propostas de fornecimento conforme apropriado a cada caso (cotações de preço, cartas-convite, licitação);

32 24 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 os fornecedores; encerramento do contrato - completar e liquidar o contrato incluindo a resolução de qualquer item pendente. 2.3 MODELAGEM DO SISTEMA DE PROCESSOS DE EMPRESA DE SOFTWARE Como já estudado anteriormente em outros módulos do curso, um processo pode ser definido como um conjunto de atividades inter-relacionadas que transformam um conjunto de entradas em resultados [ISO12207:1995]. Segundo a ISO15504 [ISO15504:1-9:1998], processo de software é um conjunto de processos utilizados por uma 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 um sistema de processo para uma organização de software. A figura 2.4 mostra este modelo, que está dividido em três agrupamentos principais: o modelo do processo, o modelo de avaliação do processo e o modelo de melhoria do processo. Modelagem do sistema de processo Modelo do processo Modelo de avaliação do processo Modelo de melhoria do processo Subsistema do processo organizacional Subsistema do processo de desenvolvimento Subsistema do processo de gerenciamento Modelo de capacidade do processo Método de determinação da capacidade do processo Modelo de melhoria baseado em avaliação Modelo de melhoria baseado em Benchmark Escala do desempenho da pratica Escala da capacidade do processo Escopo da capacidade do processo Determinação da capacidade do processo Agregação de capacidade do projeto Agregação da capacidade da organização FIGURA 2.4 Estrutura para modelagem do sistema de processo da empresa de software O modelo do processo é utilizado para descrever a organização, sua categoria, sua hierarquia, o inter-relacionamento e as instâncias dos seus processos.

33 Modelos, Padrões e Normas e a Gerência de Projetos 25 O modelo de processo descrito por [Wang1999] identifica três conjuntos de subsistemas: processo organizacional, processo de desenvolvimento de software e processo de gerenciamento. Os processos organizacionais regulam as atividades que sã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 para avaliar os pontos fortes e fracos dos processos da organização, além de identificar os pontos para melhoria. Através do modelo de melhoria do processo podem-se definir procedimentos sistemáticos para uma efetiva melhoria do desempenho dos processos da empresa mudando os processos correntes ou adicionando a eles novos processos para correção ou melhoria de problemas identificados. O processo de melhoria vem a seguir do processo de avaliação e o relacionamento entre eles forma um ciclo repetitivo até o processo da organização estar otimizado. Exemplo é o plando-check-act descrito por Campos [Campos1992]. Diversos modelos, normas e padrões definem certificação, avaliação e melhoria para o processo de software, entre eles podemos citar: a ISO9000 [ISO9000-3:1997], CMM/CMMI [Paulk1993] [Paulk1997] [CMMI:2000], ISO15504 [ISO15504:1-9:1998] e BootStrap [Kuvaja1993] [Kuvaja1994]. Apesar das empresas de software durante muito tempo negligenciarem a especificaçã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ções do que outros. Além disso, uma empresa pode, inclusive, possuir diversos padrões de processos de software sendo utilizados em projetos distintos. O reconhecimento das necessidades dos modelos de processo de software tem deixado um amplo campo de trabalho em muitas direções. As organizações que desenvolvem 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ítulos para 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 DE PROJETOS

34 26 EDITORA UFLA / FAEPE Gerência de Projetos de Software Algumas propostas de processo para gerência de projetos de software podem ser encontradas na literatura. O fluxo de gerência de projetos do RUP [Rational Unified Process] é um exemplo. Contudo, estes processos não devem ser adotados em 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 para uma empresa de software deve-se considerar seis elementos essenciais, como mostra a Figura 2.5: a política organizacional, os padrões, o processo de gerenciamento, os procedimentos, os treinamentos, e as ferramentas 5. Política Organizacional Padrões restringe o processo Processo de gerenciamento de projetos de software é implementado através de Procedimentos são apoiados por Treinamento Ferramentas de gerenciamento de projetos de software FIGURA 2.5 Modelo para criação de processo de gerenciamento de projetos de software A política organizacional estabelece as leis e as regras que governam ou restringem as operações da empresa. Ela identifica os requisitos aceitáveis do processo e/ou formas de se realizar o projeto. A política organizacional estabelece també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 as metodologias podem, por exemplo, ser utilizados para a definição dos padrões da organização. projetos. 5 Esta recomendação se aplica também a outras áreas de processo e não somente a gerência de

35 Modelos, Padrões e Normas e a Gerência de Projetos 27 Um processo de gerenciamento de projetos de software descreve como a organização gerencia a execução de seus serviços e produtos, de acordo com a polí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 na organização inicial de seu negócio através do uso de artefatos de alto nível e de baixa complexidade, em conjunto com um modelo de ciclo de vida para os projetos e o estabelecimento de fluxos de trabalho. Os processos são implementados através de procedimentos. Os fluxos de trabalho, por exemplo, podem especificar esses procedimentos, ou seja, as instruções passo-a-passo de como o processo deve ser executado. A política organizacional é 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 de métricas para posterior avaliação do processo. Os treinamentos possibilitam dar aos recursos humanos da empresa o conhecimento e habilidades necessárias para executarem os procedimentos do processo. 2.5 CONSIDERAÇÕES Como já dito anteriormente neste capítulo, os padrões e normas para SPA/SPI podem ser utilizados com o intuito de definir, avaliar e melhorar os processos de uma empresa. Todavia, apesar da sua importância, eles ainda estão sendo pouco considerados pelas empresas [Lindvall2000]. Diversos motivos dificultam o uso destes padrões, dentre eles o fato de que a definição e uso de um processo de software 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 estruturadas e estabilizadas. Porém, acreditamos que a grande ameaça à implantação destes padrões e normas, nas empresas, é o dia-a-dia da empresa que absorve praticamente todos os recursos existentes. Sendo esse um projeto interno, de longo prazo e com resultados também de longo prazo, há uma tendência à acomodação, fazendo com que as atividades sejam proteladas por diversas vezes até a desistência.

36 28 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 em definir modelos e padrões para a construção de um efetivo processo de gerenciamento 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 praticado e, porque não dizer, negligenciado. Os ambientes tradicionais das empresas têm dado suporte, em geral, somente à engenharia, assumindo um processo implícito e tendo como foco principal o produto. Acreditamos que esta visão limita as empresas no que diz respeito à tomada de decisões, ao estabelecimento e obtenção de metas organizacionais, à determinação de pontos para melhoria, à estipulação de prazos para 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 um processo padrão para gerenciamento de projetos de software. Estes modelos reúnem boas práticas para as empresas. Contudo, a implantação destes padrões exige um investimento importante dos envolvidos, para conceber um processo que venha alavancar o negócio, facilitar a vida dos envolvidos e não criar burocracia somente para atender aos requisitos descritos no modelo. Além disso, estes modelos descrevem 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 descritos também para o âmbito de empresas estruturadas. Os próximos capítulos deste módulo apresentam um exemplo de processo para gerência de projetos de software que foi construído considerando os seis elementos essenciais apresentados neste capítulo. O capítulo 3 define a política organizacional e os padrões adotados. O capítulo 4 traz o processo propriamente dito, com seu modelo 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 utilizadas em conjunto com o processo.

37 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 de software 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 no fó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ência de projetos? Que elementos você julga estar faltando? Que elementos você desconsideraria? (Coloque a sua opinião no fórum virtual).

38 3 POLÍTICA ORGANIZACIONAL E PADRÕ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. Este capítulo estabelece dois dos seis elementos essenciais definidos na seção 2.4 deste módulo. 3.1 POLÍTICA ORGANIZACIONAL CONSIDERADA PARA O PROGER Como visto no capítulo anterior, a política organizacional estabelece as leis e regras que governam ou restringem as operações da empresa de software. Ela identifica os requisitos aceitáveis do processo e/ou formas de se realizar o projeto. A polí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 baseado em dois aspectos: (1) caracterização da empresa e (2) metas que a empresa pretende atingir com a gerência de projetos Caracterização da empresa O modelo de processo para gerenciamento de projetos de software apresentado neste módulo deverá ser aplicável para empresas de pequeno e médio porte. A classificação do porte de uma empresa de software pode ser realizada considerando diversos fatores, entre eles podemos citar: faturamento, força de trabalho e comercialização anual bruta. Nós adotamos a classificação do porte da empresa baseada 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.

39 Política Organizacional e Padrões Adotados para a definição do ProGer 31 Nós optamos por considerar estas classes de empresas de software devido ao fato de serem a grande maioria. A Figura 3.1 apresenta um gráfico, também retirado do [MCT], que mostra a predominância deste tipo de organização com percentuais superiores a 80%, desde Percentual Micro Pequena Média Grande 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 rol de empresas de pequeno e médio porte. Estudos realizados também em outros países, como o de [Standish1995], também estabeleceram a predominância de empresas de pequeno e médio porte no setor computacional. Outras motivações nos fizeram optar por abordar, para o nosso exemplo, as empresas de pequeno e médio porte. Segundo Laitinen [Laitinen2000], as empresas desta classe são as que mais urgentemente necessitam de formalização de procedimentos 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 sido originalmente desenvolvidos para o âmbito de empresas bem estruturadas e departamentalizadas, ou seja, tipicamente para o âmbito de grandes empresas, isso dificulta ainda mais a orientação para empresas de pequeno e médio porte [Belloquim1999]. Outros fatores ainda agravam os problemas de gerenciamento de projetos de software em empresas de pequeno porte, tais como: inexistência de um processo

40 32 EDITORA UFLA / FAEPE Gerência de Projetos de Software definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura em processos, pouco treinamento em engenharia de software, imaturidade metodológica, crescimento ocorrido por demanda, falta de experiência administrativa por parte dos gerentes e diretores e falta de definição das metas organizacionais. Consideramos também que a empresa para a qual estamos criando o processo de 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 necessidades especí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 e introduzir padrões Metas pretendidas com a gerência de projetos As principais metas que pretendemos alcançar com a implantação do processo de gerência de projetos seriam tornar possível (através de um modelo simplificado de processo 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 DO PROGER O ProGer, modelo que será apresentado no próximo capítulo, foi concebido considerando os padrões da engenharia de processo e do gerenciamento de projetos. Foi especificado tendo como base os modelos e padrões de SPA/SPI,

41 Política Organizacional e Padrões Adotados para a definição do ProGer 33 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]), os procedimentos e normas para gerenciamento de projetos (como o PMBOK-Project Management Body of Knowledge [PMBOK2000], TQC-Total Quality Control [Campos1992] e [Royce1998]) e nos estudos empíricos realizados em empresas de software de pequeno e médio porte. Inicialmente para a especificação do ProGer, realizamos um estudo vertical nas normas e padrões para SPA/SPI, considerando somente o gerenciamento de projetos para a construção de nosso modelo padrão. Contudo, nós observamos através de estudos empíricos que os padrões e normas para SPA/SPI eram insuficientes como insumo básico para a definição de um modelo padrão para o gerenciamento de projetos em uma empresa. Um trabalho que enfatiza esta observação é apresentado por 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 temos muito que evoluir em relação às práticas de gerência para alcançarmos o conhecimento contido no PMBOK. Desta forma, passamos a considerar os processos descritos no PMBOK para o ProGer. Porém, apesar do PMBOK ser um guia mais completo na área de gerenciamento de projetos ele não considera as peculiaridades da execução de serviços e produtos de software. Nós, então, unificamos estes dois universos 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 de conhecimento do PMBOK, o CMM e a ISO/IEC15504.

42 34 EDITORA UFLA / FAEPE Gerência de Projetos de Software TABELA 3.1 Comparação entre as áreas de conhecimento do PMBOK, o CMM e a ISO/IEC15504 PMBOK CMM ISO/IEC15504 Integração Gerência de projeto integrada Gerência organizacional Escopo Tempo Custo Planejamento de acompanhamento Gerência de requisitos Acompanhamento e controle. Mas, não endereça especificamente essa questão Acompanhamento e controle. Mas, não endereça especificamente essa questão Gerência de projeto Gerência de Requisitos Gerência de projeto. Mas, não endereça especificamente essa questão. Gerência de projeto. Mas, não endereça especificamente essa questão. Aquisição Gerência de Contratos com fornecedores Não tem processos que trate especificamente essa questão. Ela é coberta na norma pela Aquisição e Fornecimento e é gerenciada da mesma forma que um projeto interno à organização Recursos Humanos Comunicação A própria concepção do modelo diz que devem se ter habilidades para executar, mas não menciona explicitamente a necessidade de gerenciamento de recursos humanos através dos projetos da organização Gerência de Configuração cobre parcialmente esse processo. A própria concepção do modelo diz que os processos devem ser comunicados, mas não menciona explicitamente a necessidade de comunicação dos produtos dos projetos para todos os envolvidos Recursos Humanos Gerência do Conhecimento Gerência de Configuração cobre parcialmente esse processo. Mas, não menciona explicitamente esse processo Risco Gerência de Risco Gerência de Risco Garantia de Qualidade Garantia de qualidade de produto e processo Gerência da Qualidade

43 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 a construção de um processo de gerência de projetos de software? Você acha que a caracterizaçã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.

44 4 PROGER: PROCESSO DE GERÊNCIA DE PROJETOS DE SOFTWARE Este capítulo apresenta o ProGer - Processo de Gerência de Projetos de Software, 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 de trabalho (seção 4.4); dos artefatos gerados no processo (seção 4.3) e de sugestões de 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 se pode 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 projetos tem por objetivo definir o início e o fim de um projeto. Este modelo pode ser dividido em fases e geralmente aborda dois aspectos principais: (1) que trabalho deve ser feito em cada fase, e (2) quem deve estar envolvido em cada fase. No que se refere aos projetos de software, diversos modelos de ciclo de vida já foram descritos, alguns exemplos são: o modelo espiral [Boehm1988] e o modelo baseado em contrato [Graham1999]. O PMBOK [PMBOK2000] reconhece estes modelos como sendo representativos para o desenvolvimento de projetos de software. Como tal, eles estão muito focados na construção de um produto ou serviço de software, isto é, estão fortemente associados aos aspectos da engenharia e desconsideram etapas do projeto que antecedem e sucedem a confecção do produto propriamente dito. Estas etapas são importantes para que uma empresa possa realizar uma avaliação mais eficaz do projeto.

45 PROGER: Processo de Gerência de Projetos de Software 37 Nós definimos um modelo de ciclo de vida para projetos de software identificando fases desconsideradas nos modelos tradicionais, ou mesmo considerados superficialmente, como é o caso do RUP-Rational Unified Process. O ProGer está dividido em cinco fases distintas (Figura 4.1): a 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 pelo PMBOK [PMBOK2000]. Um projeto de software pode ser iniciado em qualquer uma das fases, com exceçã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, descreveremos cada uma das fases do modelo de ciclo de vida. Os artefatos gerados em cada fase estão representados na seção 4.1 deste capítulo. Prospecção Proposta Execução Garantia Encerrament o 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ão identificadas as necessidades de um cliente, ou uma demanda de mercado é percebida pela empresa. A construção de um protótipo para uma demanda observada 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 da empresa. Palestras sobre produtos, construção de protótipos e levantamento de requisitos são exemplos de atividades que podem ocorrer nesta fase. Os elementos da empresa que podem estar envolvidos nesta etapa são: gerentes, diretores e técnicos.

46 38 EDITORA UFLA / FAEPE Gerência de Projetos de Software Considerando os processos de gerenciamento do PMBOK [PMBOK2000], a inicialização desta fase é dada por requisições informais de clientes, solicitação de apresentação de produtos e identificação de uma demanda aprovada pela diretoria da empresa. O planejamento desta fase é bastante diverso, podendo ir desde simples agendamentos 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 e construção de protótipos. A finalização ocorre quando o cliente envia um pedido formal para a execução de um serviço ou produto, o cliente avisa que não deseja o que foi apresentado ou a empresa estabelece a continuidade ou descontinuidade do esforço para uma demanda que foi observada. Na fase de proposta, ocorre a formalização de uma proposição da empresa para um determinado cliente interno ou externo. As características principais desta fase são: a existência de uma requisição formal, a delimitação do escopo do projeto e o 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 e comerciais. A inicialização desta fase é dada por requisições formais de clientes (um exemplo é 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 na fase de proposta é determinada pela execução de atividades como: delimitação do escopo do projeto, levantamento dos requisitos do produto ou serviço, estudo de novas 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 podem ser utilizados na etapa de execução da fase de proposta. Dois exemplos destes modelos podem ser vistos em Sanches [Sanches2001] e na [ISO9000-3:1997]. A finalização da fase de proposta ocorre quando o cliente envia um pedido solicitando a execução ou o cancelamento da proposta para o desenvolvimento de um produto ou serviço. A empresa também pode optar por cancelar uma proposta enviada para um cliente. 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 de software. Os principais artefatos gerados são: a especificação técnica, os artefatos de engenharia, o aceite do cliente e a comunicação ao cliente. A comunicação intensiva com 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 a execução do projeto. O planejamento prevê a construção de um plano de projeto que

47 PROGER: Processo de Gerência de Projetos de Software 39 envolve atividades como: decompor requisitos, estimar em detalhes o tamanho do software, estimar recursos do projeto, elaborar cronograma e negociar compromissos. O modelo do ciclo de planejamento de projetos de software descrito pela ISO [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 atividades independentes. 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 que serão utilizados no desenvolvimento do projeto. A etapa de execução determina a realização de atividades previstas no plano de projeto. A finalização da fase de execução do modelo de ciclo de vida dos projetos se dá com a entrega do produto ou serviç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 pode cancelar 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ço té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 artefatos desta 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 do cliente 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 fase de garantia. Todavia, este estabelecimento prévio pode não existir. Na etapa de execução são realizadas as atividades para adequação do produto ou serviço às solicitações do cliente. A finalização da fase de garantia ocorre quando o prazo determinado no contrato entre a empresa e o cliente findar. No período de encerramento o projeto é dado como finalizado. Todo o trabalho proposto foi concluído, aceito e garantido. Outros tipos de encerramentos podem ocorrer, 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 de planejamento, de execução e de finalização Controle e avaliação Pontos de avaliação são utilizados para sincronizar as expectativas dos stakeholders através do ciclo de vida do projeto [Kerzner2001] [PMBOK2000]. A definição de alguns pontos de avaliação permite a observação de problemas na

48 40 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 do projeto. O ponto mais importante de avaliação de um projeto é um milestone, que usualmente é 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 cultura organizacional [Royce1998] e são mais importantes de serem considerados principalmente na fase de execução do modelo de ciclo de vida de projetos propostos. Nós aconselhamos que sejam considerados os pontos de avaliação descritos no modelo de ciclo de vida do desenvolvimento adotados pelo projeto para a fase de execução. A aplicação do modelo PDCA Plan Do Check Act [Campos1992] em todas as fases do modelo de ciclo de vida também pode ser considerada. O ciclo PDCA de controle (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. O estabelecimento de metas para cada fase é importante para que o processo esteja em constante melhoria. Os itens de controle podem considerar faixas de valores padrão como, por exemplo: qualidade-padrão, custo-padrão, prazo-padrão, quantidade-padrão, entre outros. A (Action) C (Check) Atuar corretivamente Verificar os resultados da tarefa executada Definir as metas P (Plan) Definir os métodos que permitirão atingir as metas propostas Executar a tarefa (coletar dados) Educar e treinar D (DO) FIGURA 4.2 Ciclo PDCA de controle de processos A ISO15504 [ISO15504:1-9:1998] e o CMM/CMMI [Paulk1993] [CMMI:2000] definem 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

49 PROGER: Processo de Gerência de Projetos de Software 41 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 as organizaçõ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 que poderão estar envolvidos em um projeto. Estes elementos e suas funções estão apresentados 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 o cliente. deve estar apto a perceber demandas de mercado e a estabelecer parcerias para construção de soluções mais completas para clientes. realiza também renegociações de prazos e preços de projetos em execução; gerente de tecnologia responsável por pesquisar e estabelecer as tendências tecnológicas futuras da empresa. dá apoio ao desenvolvimento dos produtos/serviços e dissemina o conhecimento técnico da empresa; gerente de projetos responsável pelo gerenciamento e acompanhamento de todos os projetos de software da empresa ou de uma área específica. faz alocação e planejamento dos recursos da empresa como um todo ou da área de sua responsabilidade. revisa o planejamento feito pelo líder de projeto e acompanha o uso adequado de metodologias e padrões da empresa; gerente de processo e qualidade estabelece metas, juntamente com a diretoria, visando à melhoria do processo de software e qualidade dos produtos/serviços gerados pela empresa. é encarregado pela padronização e em auxiliar a gerência de projetos no acompanhamento dos projetos da empresa; líder de projeto responsável por planejar e gerenciar a execução de um projeto específico; técnico neste grupo se encontra os desenvolvedores de forma geral, tais como: engenheiros de software, administradores de sistemas de workflow, analistas de sistemas, administradores da infra-estrutura, analistas de negócio, arquitetos de dados, administradores de banco de dados, web designers, entre outros; cliente organização ou setor da empresa que solicita a execução de um serviço e/ou produto de software; empresa sub-contratada outra empresa a quem pode ser delegada a execução de algumas atividades do projeto de software.

50 42 EDITORA UFLA / FAEPE Gerência de Projetos de Software A Figura 4.3 apresenta uma proposta de organograma para uma empresa de software, representando uma hierarquia entre os stakeholders. Cliente DIRETOR Gerente Projetos Gerente Comercial Gerente de Tecnologia Gerente de Processo e Qualidade Empresa Subcontratada Líder da Equipe 1 Líder da Equipe 2 Líder da Equipe n Técnicos Técnicos Técnicos 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 uma empresa. Estes artefatos são: documentos de requisitos, propostas técnicas, propostas comerciais, relatórios de teste, atas de reunião, relatórios de visitas técnicas, planos de projeto, ordens de serviço e relatórios de aceite. A Figura 4.4 apresenta estes artefatos e a influência existente entre eles.

51 PROGER: Processo de Gerência de Projetos de Software 43 FIGURA 4.4 Artefatos do modelo de ciclo de vida do projeto Proposta Técnica Documento Requisitos Proposta Comercial Relatório Visita Técnica Ordem de Serviço Plano de Projeto Relatório de Aceite Relatório de Teste Ata de Reunião Os parágrafos seguintes descrevem os artefatos, suas características principais e os responsáveis por sua confecção. Ressaltamos que, o ProGer está focado mais em artefatos de gerenciamento do que em artefatos de engenharia. A Tabela 4.1 mostra os artefatos que podem ser gerados nas respectivas fases do modelo de ciclo de vida dos projetos descritos na seção 4.1. TABELA 4.1 Artefatos gerados por fase do modelo de ciclo de vida dos projetos Fase Prospecção Proposta Execução Garantia Encerramento Artefatos Documentos de requisitos e atas de reunião. Documentos de requisitos, propostas comerciais, propostas técnicas, atas de reunião. Documentos de requisitos, relatório de teste, relatórios de aceite, planos de projeto, ordens de serviço e relatórios de visitas técnicas. Relatórios de teste, atas de reuniões, ordens de serviço e relatórios de visita técnica. 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ão para nomeação dos artefatos visando facilitar o acesso aos documentos. A Tabela 4.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-

52 44 EDITORA UFLA / FAEPE Gerência de Projetos de Software de Requisitos Número_Versão 01_01 Propostas Técnica Proposta Comercial Planos de Projeto Relatório de Teste Atas de Reunião Relatórios de Visita Técnica Relatórios de Aceite Ordens de Serviço PropostaTécnica + _ + Código_Projeto + _ + Número_Versão PropostaComercial + _ + Código_Projeto + _ + Número_Versão PlanoProjeto + _ + Código_Projeto + _ + Número_Versão RelatorioTeste + _ + Código_Projeto + _ + Data (ano-mes-dia) + _ + [Número_Sequencial] AtaReuinião + _ + Código_Projeto + _ + Data (ano-mes-dia) + _ + [Número_Sequencial] RelatórioTécnico + _ + Código_Projeto + Data (ano-mes-dia) + _ + [Número_Sequencial] Aceite + _ + Código_Projeto + _ + Número_Aceite + _ + [Número_Versão] Ordem + Código_Projeto + _ + NúmeroOrdem PropostaTécnica_DVX121-01_0 1 PropostaComercial_DVX _01 PlanoProjeto_DVX121-01_01 RelatorioTeste_DVX121-01_ _01 AtaReunião_DVX121-01_ _01 RelatórioTécnico_DVX121-01_ _01 Aceite_DVX121-01_01_01 Ordem_DVX121-01_ Documento de requisitos Um requisito descreve uma condição ou aptidão que um produto de software ou serviço deve possuir para satisfazer um contrato ou uma requisição de um cliente da empresa. O documento de requisitos registra todos os requisitos funcionais e nãofuncionais deste produto ou serviço. Este artefato pode possuir diversas versões com níveis de refinamento diferenciados e deve ser descrito sempre em uma linguagem que pode ser entendida tanto por engenheiros de software quanto pelo cliente. A Figura 4.5 apresenta uma sugestão de conteúdo para este artefato. O apêndice A deste módulo apresenta um template para a confecção de um documento de requisitos. O documento de requisitos pode ser confeccionado em projetos que se encontram em todas as fases, com exceção da fase de encerramento. O mais comum é sua confecção nas fases de prospecção e proposta, com o refinamento sendo realizado na fase de execução. Este artefato pode ser feito por gerentes de projeto, gerentes comerciais, líderes de projeto e técnicos.

53 PROGER: Processo de Gerência de Projetos de Software 45 Conteúdo do Documento de Requisitos

54 46 EDITORA UFLA / FAEPE Gerência de Projetos de Software Fundação de Apoio ao Ensino, Pesquisa e Extensão - FAEPE...2 Parceria Reitor Vice-Reitor Diretor da Editora Pró-Reitor de Pós-Graduação Pró-Reitor Adjunto de Pós-Graduação Lato Sensu Coordenação do curso Presidente do Conselho Deliberativo da FAEPE Editoração Impressão Nenhuma parte desta publicação pode ser reproduzida, 145 Introdução Projeto e a Gerência de Projetos Motivação e Relevância da Gerência de Projetos As Dificuldades do Gerenciamento de Projetos de Software Estrutura do Módulo...12 Modelos, Padrões e Normas e a Gerência de PRojetos Processos de Gerenciamento da ISO/IEC PMBOK Gerência de integração de projetos Gerência de escopo de projetos Gerência de tempo de projetos Gerência de custo de projetos Gerência da qualidade de projetos Gerência de recursos humanos de projetos Gerência de comunicação de projetos Gerência de risco de projetos Gerência de aquisição de projetos Modelagem do Sistema de Processos de Empresa de Software Elementos essenciais para criar um processo de gerência de projetos Considerações...27 Política Organizacional e Padrões ADotados para A definição do ProGer política organizacional Considerada para o ProGer Caracterização da empresa Metas pretendidas com a gerência de projetos Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer...32 ProGER: Processo de Gerência de Projetos de Software Modelo de Ciclo de Vida para Projetos de Software Controle e avaliação Stakeholders Artefatos Documento de requisitos Proposta técnica Proposta Comercial...50

55 PROGER: Processo de Gerência de Projetos de Software 47 FIGURA 4.5 Sugestão de conteúdo para um documento de requisitos

56 48 EDITORA UFLA / FAEPE Gerência de Projetos de Software Proposta técnica Uma proposta técnica apresenta uma proposição de prestação de serviços para um determinado cliente. Serve como instrumento para o acompanhamento do serviço prestado ou a confecção de um produto. Este artefato pode ser confeccionado por qualquer elemento da empresa, dependendo da habilidade e dos conhecimentos que este possui no escopo que está sendo abordado. Porém, sempre deve ser revisada pelo gerente de processo e qualidade e/ou gerente de projeto. O documento de requisitos pode ser especificado dentro da proposta técnica ou estar como um anexo desta. A Figura 4.6 apresenta uma sugestão de conteúdo para uma proposta técnica. O apêndice A deste módulo apresenta um template para a confecção de uma proposta técnica. Conteúdo da Proposta Técnica

57 PROGER: Processo de Gerência de Projetos de Software 49 Parceria Reitor Vice-Reitor Diretor da Editora Pró-Reitor de Pós-Graduação Pró-Reitor Adjunto de Pós-Graduação Lato Sensu Coordenação do curso Presidente do Conselho Deliberativo da FAEPE Editoração Impressão Nenhuma parte desta publicação pode ser reproduzida, 145 Introdução Projeto e a Gerência de Projetos Motivação e Relevância da Gerência de Projetos As Dificuldades do Gerenciamento de Projetos de Software Estrutura do Módulo...12 Modelos, Padrões e Normas e a Gerência de PRojetos Processos de Gerenciamento da ISO/IEC PMBOK Gerência de integração de projetos Gerência de escopo de projetos Gerência de tempo de projetos Gerência de custo de projetos Gerência da qualidade de projetos Gerência de recursos humanos de projetos Gerência de comunicação de projetos Gerência de risco de projetos Gerência de aquisição de projetos Modelagem do Sistema de Processos de Empresa de Software Elementos essenciais para criar um processo de gerência de projetos Considerações...27 Política Organizacional e Padrões ADotados para A definição do ProGer política organizacional Considerada para o ProGer Caracterização da empresa Metas pretendidas com a gerência de projetos Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer...32 ProGER: Processo de Gerência de Projetos de Software Modelo de Ciclo de Vida para Projetos de Software Controle e avaliação Stakeholders Artefatos Documento de requisitos Proposta técnica Proposta Comercial...50

58 50 EDITORA UFLA / FAEPE Gerência de Projetos de Software FIGURA 4.6 Sugestão de conteúdo para uma proposta técnica Proposta Comercial Este artefato apresenta uma proposta comercial de prestação de serviços para um determinado cliente e deverá servir como o instrumento legal para o acompanhamento do serviço prestado. Os termos aqui estabelecidos foram definidos a partir das informações constantes na proposta técnica quando já conhecida e aceita pelas partes envolvidas. Deve contemplar acordos referentes a preço, pagamento, garantia e multas. A confecção de uma proposta comercial é de responsabilidade dos gerentes comerciais, porém deve ser aprovada pelo diretor. A Figura 4.7 sugere um conteúdo para uma proposta comercial. Um framework para construção de uma proposta comercial pode ser visto no Apêndice A. Conteúdo da Proposta Comercial

59 PROGER: Processo de Gerência de Projetos de Software 51 Parceria Reitor Vice-Reitor Diretor da Editora Pró-Reitor de Pós-Graduação Pró-Reitor Adjunto de Pós-Graduação Lato Sensu Coordenação do curso Presidente do Conselho Deliberativo da FAEPE Editoração Impressão Nenhuma parte desta publicação pode ser reproduzida, 145 Introdução Projeto e a Gerência de Projetos Motivação e Relevância da Gerência de Projetos As Dificuldades do Gerenciamento de Projetos de Software Estrutura do Módulo...12 Modelos, Padrões e Normas e a Gerência de PRojetos Processos de Gerenciamento da ISO/IEC PMBOK Gerência de integração de projetos Gerência de escopo de projetos Gerência de tempo de projetos Gerência de custo de projetos Gerência da qualidade de projetos Gerência de recursos humanos de projetos Gerência de comunicação de projetos Gerência de risco de projetos Gerência de aquisição de projetos Modelagem do Sistema de Processos de Empresa de Software Elementos essenciais para criar um processo de gerência de projetos Considerações...27 Política Organizacional e Padrões ADotados para A definição do ProGer política organizacional Considerada para o ProGer Caracterização da empresa Metas pretendidas com a gerência de projetos Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer...32 ProGER: Processo de Gerência de Projetos de Software Modelo de Ciclo de Vida para Projetos de Software Controle e avaliação Stakeholders Artefatos Documento de requisitos Proposta técnica Proposta Comercial...50

60 52 EDITORA UFLA / FAEPE Gerência de Projetos de Software FIGURA 4.7 Conteúdo para uma proposta comercial Plano de Projeto Um plano de projeto é um documento formal e aprovado que é utilizado para gerenciar a execução de um projeto [PMBOK2000]. Um plano de projeto delimita o escopo da execução do projeto levando em conta as condicionantes (opções de decisão) escolhidas pelo cliente e anteriormente aprovadas na proposta técnica e comercial. 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ão do 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 metodologia e o modelo de ciclo de vida do desenvolvimento, os artefatos que serão utilizados e gerados, as ferramentas necessárias, o cronograma de atividades com os recursos alocados, 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 o andamento dos trabalhos e são confeccionados por líderes de projeto com aprovação do gerente de projeto e/ou gerente de processo e qualidade. A Figura 4.8 apresenta uma sugestão de conteúdo para um plano de projeto. Um modelo de plano de projeto pode ser visto no Apêndice A.

61 PROGER: Processo de Gerência de Projetos de Software 53 Conteúdo do Plano de Projeto

62 54 EDITORA UFLA / FAEPE Gerência de Projetos de Software Parceria Reitor Vice-Reitor Diretor da Editora Pró-Reitor de Pós-Graduação Pró-Reitor Adjunto de Pós-Graduação Lato Sensu Coordenação do curso Presidente do Conselho Deliberativo da FAEPE Editoração Impressão Nenhuma parte desta publicação pode ser reproduzida, 145 Introdução Projeto e a Gerência de Projetos Motivação e Relevância da Gerência de Projetos As Dificuldades do Gerenciamento de Projetos de Software Estrutura do Módulo...12 Modelos, Padrões e Normas e a Gerência de PRojetos Processos de Gerenciamento da ISO/IEC PMBOK Gerência de integração de projetos Gerência de escopo de projetos Gerência de tempo de projetos Gerência de custo de projetos Gerência da qualidade de projetos Gerência de recursos humanos de projetos Gerência de comunicação de projetos Gerência de risco de projetos Gerência de aquisição de projetos Modelagem do Sistema de Processos de Empresa de Software Elementos essenciais para criar um processo de gerência de projetos Considerações...27 Política Organizacional e Padrões ADotados para A definição do ProGer política organizacional Considerada para o ProGer Caracterização da empresa Metas pretendidas com a gerência de projetos Modelos, NOrmas e Padrões Utilizados para a Definiçao do ProGer...32 ProGER: Processo de Gerência de Projetos de Software Modelo de Ciclo de Vida para Projetos de Software Controle e avaliação Stakeholders Artefatos Documento de requisitos Proposta técnica Proposta Comercial...50

63 PROGER: Processo de Gerência de Projetos de Software 55 FIGURA 4.8 Sugestão de conteúdo para um plano de projeto Relatório de teste Um relatório de teste tem por finalidade o registro dos testes realizados em conjunto com os clientes (validação dos requisitos do projeto). Serve de documento base para a especificação de novos requisitos, e análise e previsão para a realização de alterações no produto ou serviço de software. Deve possuir a concordância dos usuários que estão envolvidos no processo de teste. É importante durante a confecção deste artefato que seja feita uma referência aos requisitos que estão sendo testados. Este artefato é confeccionado por técnicos e/ou líderes de projeto e pode ser utilizado para validar um único ou um agrupamento de requisitos ao mesmo tempo. A Figura 4.9 apresenta um modelo para relatório de casos de teste. RELATÓRIO DE TESTE PROJETO <NOME DO PROJETO> CLIENTE <NOME DO CLIENTE> CONTRATO: <IDENTIFICADOR DO CONTRATO> Nome do Projeto Data do Teste Repetição deste teste [ ]1 o [ ]2 o [ ]3 o [ ]4 o [ ]5 o [ ]6 o [ ]7 o [ ]8 o [ ]9 o [ ]10 o [ ]11 o [ ]12 o Relato do Teste e Observações Empresa <Empresa> <Cliente> <Cliente> Nome Assinatura FIGURA 4.9 Modelo de relatório de teste Ata de reunião

64 56 EDITORA UFLA / FAEPE Gerência de Projetos de Software As atas de reunião devem registrar todas as reuniões internas e externas da empresa descrevendo os tópicos discutidos e as metas estabelecidas. As atas de reuniã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 um modelo para este artefato. ATA DE REUNIÃO PROJETO <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 Rubricas <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/ /fone>. Qualquer dúvida ou discordância, favor entrar em contato com o redator. FIGURA 4.10 Modelo de ata de reunião 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 algum procedimento novo. Estes relatórios geralmente são confeccionados por técnicos e lí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 visita técnica.

65 PROGER: Processo de Gerência de Projetos de Software 57 Nome do Projeto: Nome do Cliente: Identificador do Contrato: Solicitante: Local: Problema / Requisição RELATÓRIO VISITA TÉCNICA Data Solicitação: Data Entrega Serviço: Solução Observação Empresa <Empresa> <Cliente> <Cliente> Nome Assinatura FIGURA 4.11 Modelo de relatório de visita técnica Relatório de aceite Um 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 a resolução dos problemas encontrados. Nós definimos dois tipos de relatórios de aceite: 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 pelo estabelecimento de entregas parciais do serviço ou produto. Um exemplo pode ser o aceite 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.

66 58 FIGURA 4.12 EDITORA UFLA / FAEPE Gerência de Projetos de Software Modelo de relatório de aceite Os relatórios de aceite utilizam o documento de requisitos como base e registram a satisfação do cliente, a estratégia para resolução dos problemas 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. REQUISITOS REQUISITO FUNCIONAL <código do requisito> DESCRIÇÃO <descrição do requisito> AVALIAçÃO <OK, não conforme, conforme com restrições> REQUISITO NÃO DESCRIÇÃO AVALIAçÃO FUNCIONAL <código do requisito> <descrição do requisito> < OK, não conforme, conforme com restrições> II. PRODUTOS ENTREGUES PRODUTO OBSERVAÇÃO AVALIAçÃO <nome do <descrição da observação> < OK, não conforme, conforme com restrições> produto> 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ÇO ITEM OBSERVAÇà AVALIAçÃO O Qualidade do atendimento < observação> < excepcional,bom, razoável,insuficiente, péssimo> Qualidade dos produtos entregues... V. CONCLUSÃO ρ Serviço Considerado Conforme ρ Serviço Considerado Conforme com Restrição ρ Serviço Considerado Não-Conforme VI. OBSERVAÇÃO: apontados pelo cliente e estabelecimento de novas metas para correção de nãoconformidades. Um relatório de aceite pode ser confeccionado por um líder de projeto e/ou gerente de projeto. O apêndice A apresenta um template para este artefato.

67 PROGER: Processo de Gerência de Projetos de Software Ordem de Serviço Uma ordem de serviço registra uma requisição formal de um cliente para a realizaçã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. A liberação do serviço solicitado necessita do aval do gerente de projeto ou gerente de processo e qualidade para que possa ser realizado. A Figura 4.13 apresenta um modelo para este artefato. Nome do Projeto: Nome do Cliente: Identificador do Contrato: Solicitante: Local: Solicitação ORDEM DE SERVIÇO Data Solicitação: Data Entrega Serviço: Custo Associado Observação Empresa <Empresa> <Cliente> <Cliente> Nome Assinatura 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 que sã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

68 60 EDITORA UFLA / FAEPE Gerência de Projetos de Software deverão ser realizadas, a interconexão entre estas atividades, os atores envolvidos e os produtos (artefatos, produtos de manufatura, comunicação, etc.) que serão gerados para satisfazer uma necessidade do negócio. A ordem da execução de um fluxo de trabalho pode ser serial, paralela e/ou condicional. Os fluxos de trabalho podem ser descritos informalmente ou formalmente. Fluxos de trabalho formais são descritos através de linguagens apropriadas, as WDLs (Workflow Description Languages). Algumas destas linguagens são derivadas de modelos 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 utilizando flowchart descrito em [Kerzner2001], por ser mais simples e permitir que sejam declarados também os executores de cada atividade. A Figura 4.14 apresenta as primitivas que o flowchart utiliza para descrever os fluxos de trabalho. Elipses mostram materiais, informações ou ações (entradas) que iniciam o fluxo ou para mostrar o resultado do término (saída) do fluxo 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 onde uma questão está sendo realizada ou uma decisão é requerida A Um círculo com uma letra ou um número identifica uma quebra no fluxo que é continuada na mesma página ou em outra página FIGURA 4.14 Primitivas do flowchart Setas mostram a direção do fluxo No ProGer estabelecemos três fluxos de trabalho para uma empresa de pequeno ou médio porte: fluxo de captação de projetos, fluxo de execução de projetos 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ção 4.1. O Apêndice B apresenta em detalhes os fluxos do ProGer. A seguir faremos uma apresentação sucinta destes fluxos Fluxo de captação de projetos O fluxo de captação de projetos define os procedimentos e artefatos que devem ser gerados pela empresa quando ocorre a identificação de uma demanda ou

69 PROGER: Processo de Gerência de Projetos de Software 61 solicitação de um serviço ou produto pelo cliente. Este fluxo termina quando uma proposta comercial é entregue ao cliente ou um produto, serviço ou protótipo de uma demanda que foi visualizada é finalizado. Cancelamentos podem ocorrer por parte do cliente ou da empresa. Este fluxo de trabalho é utilizado nas fases de prospecção e proposta 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 fluxo completo está definido no Apêndice B deste módulo. Início Cliente solicita serviço ou uma devmanda é visualizada Levantamento de requisitos Confecção do documento de requisitos Construção de protótipo? N S Confecção de plano de projeto Execução das atividades do plano de projeto Confecção e aprovação de proposta técnica Confecção e aprovação de proposta comercial Proposta comercial é entregue ao cliente Término FIGURA 4.15 Resumo do fluxo de captação de projetos A confecção de propostas técnicas, propostas comerciais e planos de projeto necessitam de estimativas de tempo e custo, necessárias para a realização do escopo proposto no projeto. Diversas técnicas de estimativas existem com o intuito de prever tamanho, esforço, prazo e custo para produtos e serviços de software, tais como [Trindade2000] [Braga1996] e [Boehm1981]. Muitas destas técnicas requerem uma grande variedade de fatores de entrada, incluindo dados históricos, medidas de complexidade de sistemas, análise de equipes de desenvolvimento, algumas restrições de projeto e estimativas do volume de código (o tamanho do projeto).

70 62 EDITORA UFLA / FAEPE Gerência de Projetos de Software Porém, para que as técnicas sejam efetivas a empresa deve encontrar as condições apropriadas ao seu negócio [Sanches2001]. As empresas de pequeno porte possuem de forma geral algumas limitações que devem 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, alto rodízio de pessoal, imaturidade metodológica, projetos executados sem planejamento detalhado, 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 dos métodos e técnicas utilizadas na fase de elaboração de estimativas e nas demais fases do processo de planejamento, bem como um levantamento preliminar das ferramentas disponíveis para apoio às tarefas. Porém também conclui que, os métodos para as estimativas, planejamento e controle das atividades devem ser simples, rápidos, eficazes e apresentados em uma linguagem mais aderente aos negócios empresariais. Nós também acreditamos que as empresas de pequeno porte devem utilizar técnicas simples para estimar produtos e serviços de software, porém estas técnicas devem estar formalizadas e entendidas pelos elementos da empresa envolvidos no processo. Uma técnica que pode ser utilizada para estimar está focada no conhecimento e capacidade de estimar das pessoas. Desta forma, está apto a estimar qualquer pessoa da empresa, dando prioridade àquelas que possuírem mais experiência na tecnologia 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 o projeto deve satisfazer. Para cada requisito do produto, ou serviço detalhado no documento de requisitos, uma quantidade de esforço em horas deve ser estimada. Esta quantidade de horas deve considerar de preferência sempre um profissional de nível médio. A Tabela 4.3, confeccionada através da observação de realizamos em projetos em algumas empresas de pequeno porte, apresenta um exemplo de como os níveis de profissionais podem ser considerados. TABELA 4.3 Sugestão de categorização de níveis de profissionais para uma empresa de pequeno porte Nível Projeto: do Roteamento Profissionalde Caminhões Categoria de Profissionais Requisito: 1[RF001] Cadastramento Gerentes especializados de Rotas e Caminhões consultores Dresser na mineração de Tamanduá 2 Gerentes e técnicos masters Tipo de atividade: Engenharia de software Complexidade 3 :03 Líderes de projetos e técnicos seniores Prioridade: 4 essencial Técnicos juniores Horas previstas 5 para realização: Técnicos trainees 24 e estagiários Nível de profissional considerado: 3

71 PROGER: Processo de Gerência de Projetos de Software 63 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ção do 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á gasto estabelecendo para cada requisito a ser realizado um profissional específico ou níveis de profissionais e quantidade necessária de profissionais. A estimativa de custo monetário para o projeto pode ser realizada baseando-se na quantidade de horas previstas para a realização de cada requisito do projeto e no custo da hora do profissional considerado na estimativa. A estimativa de prazo do projeto é feita através da distribuição da disponibilidade dos recursos humanos que executarão as atividades do projeto. A Tabela 4.4 trás um resumo de métricas que podem ser utilizadas no fluxo de captaçã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 Projetos T1 = 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

72 64 EDITORA UFLA / FAEPE Gerência de Projetos de Software Fluxo de execução de projetos O fluxo de execução de projetos se inicia após a aprovação de uma proposta comercial ou liberação da diretoria para a execução de um projeto interno da empresa. 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 seu detalhamento, (2) cancelamento do projeto por parte da empresa ou do cliente e (3) o cliente não deu um aceite satisfatório implicando na necessidade de um novo plano de projeto. Este fluxo de trabalho ocorre na fase de execução do modelo de ciclo de vida para projetos de software. A Figura 4.17 apresenta um resumo do fluxo de execução de projetos. O fluxo completo está definido no Apêndice B deste módulo.

73 PROGER: Processo de Gerência de Projetos de Software 65 Início Análise da proposta técnica/comercial aprovada Confecção e aprovação do plano de projeto Execução das atividades do plano de projeto Problemas/ novos requisitos? S Determinação da estratégia para resolução dos problemas Realização das alterações no plano de projeto N Obtenção do aceite do projeto É necessário ajustes? S Planejamento dos ajustes Realização das atividades de ajuste N Produto/Serviço é entregue ao cliente Término 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ção de projetos a elaboração de um plano de projeto, que define a estrutura de divisão total do trabalho do projeto em etapas e atividades independentes. Outros elementos também são definidos antes de efetivamente iniciar os trabalhos do projeto, tais como: as técnicas, metodologias, ferramentas e o modelo de ciclo de vida de desenvolvimento que serão adotados; artefatos que serão utilizados e gerados; riscos; cronograma de atividades; e 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 o andamento dos trabalhos e delimita o escopo da execução do projeto, levando em conta as condicionantes escolhidas pelo cliente e anteriormente aprovadas na proposta técnica e comercial.

74 66 EDITORA UFLA / FAEPE Gerência de Projetos de Software Uma atividade a ser realizada em um projeto é determinada por um requisito funcional ou não-funcional a ser cumprido. Uma tarefa é uma ocorrência da execução desta atividade. Sempre que uma tarefa for executada, o executor deve estimar o percentual de realização do requisito. Uma classe de tipo de atividade deve sempre ser 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 que tipo de atividade realizou. No caso de engenharia de software, um tipo de atividade poderia ser: levantamento de requisitos, análise, projeto, implementação e teste. Desta forma, o apontamento de uma tarefa para uma atividade (requisito) de um projeto pode ser feito como apresentado na Figura FIGURA 4.18 Exemplo de estimativa de tempo para um requisito de um projeto O apontamento (registros) de todas as horas gastas nos requisitos do projeto, e Projeto: Roteamento de Caminhões Requisito: [RF001] Cadastramento de Rotas dos Caminhões Dresser na mineração de Tamanduá Tipo de atividade: Engenharia de software Subclasse da atividade : Projeto Data da execução da atividade: 12/12/2001 Total de horas gastas: 10 horas Percentual realizado do requisito: 10% Problemas encontrados: ok Observações: xxx xxxx xxxx suas respectivas taxas de realização são utilizados para obtenção de algumas métricas. A taxa de realização, por exemplo, permite que os líderes de projeto possam visualizar o quanto o projeto evoluiu. O registro dos problemas encontrados em campo, durante o apontamento das horas, auxilia os líderes para a identificação de problemas e determinação de estratégias para a sua resolução. Nós recomendamos, para empresas de pequeno porte, que o apontamento de horas seja feito 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 e aceitar o produto ou serviço de software que foi encomendado. Durante as atividades de validação, algumas não-conformidades podem ser encontradas e a empresa deve estabelecer estratégias para a realização dos ajustes (que serão registradas nos documentos de aceite parcial e final).

75 PROGER: Processo de Gerência de Projetos de Software 67 A Tabela 4.5 apresenta algumas métricas que podem ser utilizadas no fluxo de execuçã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ço h = 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 do apontamento 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 * 100 TTX (percentual de realização do projeto) = somatório de todas (HE / THE * x) * 100 do projeto Fluxo de avaliação de projetos O fluxo de avaliação de projetos estabelece atividades que comparam o que foi planejado para ser executado e o que foi efetivamente realizado. A Figura 4.19 apresenta um resumo do fluxo de 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ídios para tomar decisões de melhoria do processo de software. A análise do desempenho de um projeto de software depende das metas que a empresa pretende atingir com a melhoria de seu processo. Um exemplo de algumas análises que poderiam ser feitas inclui: análise da satisfação do cliente; desempenho das estimativas (esforço, prazo e custo); análise das possíveis causas para os problemas encontrados em campo;

76 68 EDITORA UFLA / FAEPE Gerência de Projetos de Software desempenho dos recursos humanos; verificação se o trabalho realizado foi dentro do escopo inicialmente pretendido; etc. Início Análise do desempenho do projeto Identificação de melhorias para o processo Melhorias aprovadas? N S Introdução de melhoria no processo 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 melhorias possam ser identificadas para o processo de software. Um exemplo pode ser a análise do desempenho das estimativas, que possibilita a determinação de quais recursos humanos estão mais aptos a estimar para que clientes. Isto possibilita que a empresa direcione estes elementos para a realização de planejamentos mais realí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ção na 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.

77 PROGER: Processo de Gerência de Projetos de Software 69 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 * CONSIDERAÇÕES Objetivamos com este capítulo apresentar um exemplo de processo de gerência de projetos que pode ser utilizado em empresas de pequeno e médio porte. O processo aqui apresentado já foi utilizado como base para a modelagem do processo de gerência de projetos de algumas empresas de software. O experimento mais significativo do uso deste processo está relatado em Rouiller [Rouiller2001], que descreve o acompanhamento de 81 projetos de software em uma empresa de pequeno porte. Este trabalho também apresenta um framework conceitual para a construçã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.

78 70 EDITORA UFLA / FAEPE Gerência de Projetos de Software TABELA 4.7 Relação de alguns procedimentos do proger e as áreas de conhecimento do PMBOK. Área do Conhecimento Gerência de Integração Gerência de Escopo de Projetos Gerência de Tempo Gerência de Custo Gerência da Qualidade Gerência de Recursos Humanos Gerência de Comunicação Gerência de Risco Gerência de Aquisição Procedimentos do ProGer desenvolvimento e acompanhamento do plano de projeto controle da execução do plano de projeto resolução de problemas durante a execução controle das versões e mudanças dos artefatos reuniões periódicas para estabelecimentos de metas e de acordos uso dos fluxos de trabalho revisão dos artefatos definição do escopo do projeto através documento de requisitos aprovação do documento de requisitos pelo cliente revisão da especificação do documento de requisitos uso do modelo de ciclo de vida e seus artefatos associados uso 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 desenvolvimento e acompanhamento do plano de projeto definição da rastreabilidade entre os requisitos estimativa da duração das atividades dos requisitos do projeto apontamento de esforço gasto para desenvolver as atividades acompanhamento periódico da evolução do projeto desenvolvimento e acompanhamento do plano de projeto estimativa de custos para cada atividade do projeto baseada no esforço apontamento de esforço gasto para desenvolver as atividades análise dos dados históricos de outros projetos determinação de metas de qualidade a serem atingidas avaliação periódica do projeto, baseado nas metas de qualidade desejada avaliação da satisfação do cliente através do relatório de aceite registro e análise dos problemas na execução dos projetos desenvolvimento e acompanhamento do plano de projeto realização de estimativas e avaliação do desempenho dos projetos uso do ciclo PDCA controle da disponibilidade dos recursos registro das funções e responsabilidade de cada recurso uso dos fluxos de trabalho desenvolvimento e acompanhamento do plano de projeto identificação das habilidades dos recursos humanos acompanhamento e análise do desempenho dos recursos humanos definição de milestones e reuniões periódicas uso dos fluxos de trabalho reuniões periódicas disseminação do conhecimento adquirido pelos recursos humanos da empresa desenvolvimento e acompanhamento do plano de projeto identificação dos riscos do projeto e estabelecimento de planos de contingência desenvolvimento e acompanhamento do plano de projeto desenvolvimento da proposta comercial desenvolvimento do documento de requisitos

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

80 72 EXERCÍCIOS DE FIXAÇÃO: 1.Considerando as metas que a empresa de software pretendia alcançar com a implantação de um processo de gerência de projetos (identificada no capítulo 3 deste EDITORA UFLA / FAEPE Gerência de Projetos de Software mó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). Lembrando que 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 este comparativo, inclua sugestões de melhorias em artefatos e fluxos para tornar o ProGer aderente ao CMMI e apresente suas justificativas. (Pode ser utilizada a ISO15504 também para este exercício). 4.Se a sua empresa desejasse implantar um processo de gerência de projetos, de que forma você o faria? (apenas para meditar).

81 5 FERRAMENTAS PARA APOIO AUTOMATIZADO AO PROGER Além de outros fatores, realizar o gerenciamento de projetos sem automação impossibilita 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 de gerenciamento de projetos disponíveis no mercado não são específicos para software, dificultando o processo. A engenharia de processo tem se esforçado no sentido de definir modelos e padrõ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 crescimento da cultura de processo têm levado as empresas à criação de ambientes de software mais eficientes, um exemplo é o PSEEs - Process-Centered Software Engineering Environment. Os PSEEs integram tanto os requisitos do produto, que são o foco da engenharia de software, como os requisitos do processo, que são o foco do gerenciamento do projeto e da engenharia de processo. Apesar de reconhecer a importância do processo de software e sua natureza dinâ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 os mecanismos para integração. No conceito mais amplo de PSEEs ainda inexistem ferramentas disponíveis para uso efetivo pelas empresas. De forma geral são mais comuns os gerenciadores de processos, que são uma camada dos PSEEs. Todavia, estes gerenciadores desconsideram alguns elementos importantes no gerenciamento de projetos tais como: o acompanhamento do plano de projeto, o controle da execução dos projetos, o registro dos problemas encontrados em campo, o registro das estimativas e o apontamento do esforço. O trabalho de Reis [Reis2000] faz uma retrospectiva e análise dos PSEEs. Outra abordagem que pode ser utilizada para gerenciamento de projetos é o WFMSs - Workflow Management Systems. O WFMSs são sistemas que foram

82 66 EDITORA UFLA / FAEPE Gerência de Projetos de Software originalmente construídos para a indústria manufatureira e para utilização em processos de negócio. Desta forma, não consideram a dinamicidade do processo de software. Os WFMSs também trabalham com o conceito da instanciação de um processo pré-definido, e cada processo de software é único. É possível tomar como base processos padrões de software, mas não instanciá-los como é feito na manufatura. Reis [Reis2000] estabelece que existe pouca diferença entre PSEEs e produtos workflow (fluxo de trabalho), com exceção que produtos de workflow provêem suporte mais direto a processos organizacionais. Nós concordamos com esta colocação. Flexibilizar e simplificar o PSEEs e WFMSs seria uma tarefa necessária para a construção de ambientes que pudessem realizar o gerenciamento dos projetos nas empresas, principalmente no que se refere à obtenção de métricas para introdução de melhorias em curto prazo. As ferramentas para CSCW-Computer-supported Cooperative Work exploram o uso do computador para facilitar e garantir o trabalho colaborativo entre as pessoas. As ferramentas de CSCW podem ser utilizadas também com o intuito de gerenciar projetos. Contudo, uma ferramenta de CSCW é frouxa e não permite o estabelecimento das responsabilidades e interdependência entre as atividades a serem realizadas em um plano de projeto de software. Elas impossibilitam um controle mais efetivo da execução se desconsiderarmos a confecção de um aplicativo específico projetado sobre esta plataforma. Algumas ferramentas para gerenciamento de projetos podem ser encontradas no mercado, contudo não são específicas para software. Melo [Melo2000] apresenta alguma destas ferramentas, descrevendo suas características, funcionalidades e seus pontos fortes e fracos. Todavia estas ferramentas, em sua maioria, possibilitam somente o registro da estrutura da divisão do trabalho do projeto, tornando o acompanhamento do projeto de software precário. A confecção dos planos está desatrelada dos processos da empresa impossibilitando manter a integridade com os elementos do processo de software. A dinamicidade da execução de um projeto de software também dificulta o acompanhamento do projeto utilizando estes tipos de ferramentas, 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 pode ser 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 de acesso é geralmente precário, baseado em acesso ao documento e não à atividade do projeto. O trabalho de Moura [Moura2000] relaciona algumas ferramentas que podem ser utilizadas para a gestão de projetos de software.

83 Ferramentas para Apoio Automatizado ao ProGer 67 Nas próximas seções apresentaremos um exemplo de conjunto de ferramentas que já foi adotada em conjunto com o ProGer, que serve como sugestão para apoiar o processo definido no capítulo FERRAMENTAS UTILIZADAS EM CONJUNTO COM O PROGER 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 aos citados 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 como o Open Office Writer ( 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 e projetos, 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).

84 68 EDITORA UFLA / FAEPE Gerência de Projetos de Software O MS Project pode ser substituído por outra ferramenta open source para gerenciamento de projetos, como o dotproject ( 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 como o Open Office Calc ( 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, ou requisitos 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: Existem inúmeras outras opções de issue trackers que podem ser utilizados no lugar do Mantis, exemplos: Bugzilla ( e Eventum (

85 Ferramentas para Apoio Automatizado ao ProGer FreeVCS Ferramenta freeware. Ferramenta de controle de versões de arquivos, importantíssima para gerência de configuração. Pode ser utilizada como ferramenta de apoio para praticamente todos os artefatos e documentos de um projeto. Mais informações a respeito das funcionalidades da ferramenta podem ser encontradas no seguinte endereço: Existem opções open source para realizar o controle de versão como o popular Subversion ( Microsoft outlook Ferramenta proprietária da empresa Microsoft. Ferramenta de envio e recebimento de s, utilizado como ferramenta de apoio 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 da ferramenta podem ser encontradas no seguinte endereço: Uma alternativa open source é o Thunderbird ( US/thunderbird/) 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 que esteja fisicamente longe e a qualquer momento que o mesmo esteja conectado. Também pode ser utilizada como apoio à elaboração e refinamento dos seguintes documentos, entre outros: proposta técnica; proposta comercial; documentos de requisitos;

86 70 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 podem ser encontradas no seguinte endereço: 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 ProjectSpace 6 [Rouiller2001] e considera as particularidades do ProGer. Esta ferramenta foi construída na plataforma Lotus-Notes, que é um ambiente adequado para trabalho cooperativo e que envolve muita colaboração humana. A Figura 5.1 mostra uma visão do cadastramento de projetos. A notificação ao gerente de processo e qualidade e ao diretor é feita automaticamente quando um novo projeto é criado. Cada projeto inicia-se em uma fase específica, baseada no modelo de ciclo de vida de projetos descritos pelo ProGer. Para cada fase são associados os recursos que 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ção de reuniões. Lembrando que, um projeto pode ser iniciado em qualquer fase, com exceção do encerramento. A Figura 5.2 apresenta uma visão do cadastramento da fase 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.

87 Ferramentas para Apoio Automatizado ao ProGer 71 FIGURA 5.1 Visão do cadastramento de projetos FIGURA 5.2 Visão do cadastramento de fases do projeto

88 72 EDITORA UFLA / FAEPE Gerência de Projetos de Software Após a criação de um projeto em uma determinada fase macro-atividades 7 são criadas pelo líder de projeto. O gerente de projeto é notificado da criação de todas as macro-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 do esforç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 de uma macro-atividade. FIGURA 5.3 Visão do cadastramento de macro-atividades Posteriormente, os executores registram os tempos gastos (apontamento de horas) nas macro-atividades, relacionando o tipo de atividade realizada. O executor faz uma estimativa da realização da macro-atividade, neste momento. Problemas encontrados em campo são notificados ao líder de projeto, neste momento. A Figura 5.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 de software e possuem uma subclasse de atividade associada.

89 Ferramentas para Apoio Automatizado ao ProGer 73 FIGURA 5.4 Visão do apontamento de horas nas macro-atividades Informações gerenciais também podem ser obtidas através de relatórios solicitados pela gerência e diretoria. A Figura 5.5 apresenta uma visão dos projetos por 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 Figura 5.6.

90 74 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ão diária do trabalho do executor.

91 Ferramentas para Apoio Automatizado ao ProGer 75 FIGURA 5.7 Uma visão das horas gastas por colaborador FIGURA 5.8 Visão diária do trabalho do executor