GP 01

FACULDADE DE TECNOLOGIA DE JOO PESSOA
MAXWELL ANDERSON IELPO DO AMARAL
UMA PROPOSTA DE PROJETO PARA IMPLANTAO DO CMMI-DEV NVEL 2 DE MATURIDADE CONFORME O GUIA PMBOK
JOO PESSOA 2010
Monografia apresentada ao Curso de Especializao em Gerenciamento de Projetos do Instituto de Paraibano de Ps-Graduao da Faculdade de Tecnologia de Joo Pessoa, como requisito parcial para obteno do ttulo de Especialista em Gerenciamento de Projetos. Orientador: Prof. Esp. Francisco Eriko, PMP
JOO PESSOA 2010
Monografia apresentada ao Curso de Especializao em Gerenciamento de Projetos da Faculdade de Tecnologia de Joo Pessoa, como requisito parcial para obteno do ttulo de Especialista em Gerenciamento de Projetos.
Aprovada em 28 de maro de 2010.
COMISSO ORGANIZADORA
Prof. Esp. Francisco Eriko Brito, PMP Faculdade de Tecnologia de Joo Pessoa Orientador
Prof. Ms. Ricardo Roberto Faculdade de Tecnologia de Joo Pessoa Membro da banca
Prof. Ms. Jorge Loureiro Dias Faculdade de Tecnologia de Joo Pessoa Membro da banca
minha amiga, conselheira e esposa, Lu.
RESUMO
Este trabalho discorre sobre o planejamento para a implantao da melhoria de processos aplicada em empresas de desenvolvimento de software sem um processo organizacional definido. O ponto central da pesquisa est inserido no contexto da gerncia de projetos, especificamente no planejamento, e alicerada nos princpios do Guia de Conhecimentos em Gerenciamento de Projetos (PMBOK) do Instituto de Gerenciamento de Projetos (PMI) dos Estados Unidos. Um esforo maior se concentrar na investigao e no planejamento para aplicao da melhoria de processos de software baseada nas melhores prticas sugeridas pelo Capability Maturity Model Integration for Development, nvel 2 de maturidade (CMMI-DEV L2) criado sob encomenda pelo Instituto de Engenharia de Software (SEI), da Universidade Carnegie Mellon, dos EUA. O processo para a implantao do CMMI-DEV baseado no trabalho de Kulpa e Johnson (2008) em um cenrio fictcio que reflete a realidade de muitas empresas brasileiras. enfatizada a ateno aos problemas decorrentes do impacto da mudana de cultura organizacional, da falta de visibilidade ou da m expectativa dos envolvidos, da m gesto tcnica em gerenciamento de projetos de software, da inexistncia da garantia da qualidade, dentre outros problemas. Resumidamente, este trabalho contm uma descrio detalhada do estudo de caso, seguido de um planejamento detalhado para esta implantao, contendo os produtos de trabalho de entrada e sada necessrios, pertencentes ao grupo de processos correlato do PMBOK, focando mais o controle do que a agilidade do projeto.
Palavras-chave: planejamento, projeto, processo, CMMI-DEV, PMBOK.
ABSTRACT
This work discusses the planning for the deployment of process improvement applied in software development companies without a defined organizational process. The central point of research is inserted in the context of project management, specifically in planning, and based on the principles Guide of the Project Management Body of Knowledge (PMBOK) of Project Management Institute (PMI) of USA. A greater effort will focus on research and planning for implementation of software process improvement based on best practices suggested by the Capability Maturity Model Integration for Development, level 2 of maturity (CMMI-DEV L2) custom created by the Software Engineering Institute (SEI) of Carnegie Mellon University, U.S. The process to implement the CMMI-DEV based on work by Kulpa and Johnson (2008) in a fictional scenario reflects the reality of many Brazilian companies. Is emphasized attention to problems arising from the impact in changing organizational culture, lack of visibility or poor expectation of those stakeholders, mismanagement technical project management software, the lack of quality assurance, among other problems. Briefly, this work contains a detailed case study, followed by a detailed planning for this deployment, containing the input and output artifacts necessary, belonging to the group of process correlate of PMBOK, focusing more control than the agility of the project.
Keywords: planning, design, process, CMMI-DEV, PMBOK.
LISTA DE FIGURAS
Figura 1 - Restries .......................................................................................................... 16 Figura 2 - Grupo de Processos de Planejamento ............................................................... 17 Figura 3 - Representao por estgios ............................................................................... 19 Figura 4 - Representao Contnua ................................................................................... 20 Figura 5 - Processo de Implantao do CMMI-DEV ........................................................ 21 Figura 6 - Estrutura Organizacional da eGovSS ................................................................ 28
LISTA DE TABELAS
Tabela 1: Resultados da melhoria antes e aps a implantao do CMMI ................................ 24 Tabela 2: Quantidade de linhas de cdigo por unidade organizacional ................................... 32 Tabela 3: Quantidade de recursos humanos e alocao para produo de linha de cdigo ..... 33 Tabela 4: Quantidade de linhas de cdigo e EDB por desenvolvedor. .................................... 33 Tabela 5: Indicadores de atendimento das solicitaes de manuteno ................................... 34 Tabela 6: Solicitaes registradas, atendidas e no atendidas por desenvolvedor. .................. 35 Tabela 7: Plano resumido de cargos e salrios da empresa ...................................................... 43
LISTA DE SIGLAS
CLT Consolidao das Leis Trabalhistas CM Gesto de Configurao CMM Capability Maturity Model CMMI Capability Maturity Model Integration CMMI-DEV Capability Maturity Model Integration for Development CMMI-DEV L2 Capability Maturity Model Integration for Development level 2 CPM Mtodo do Caminho Crtico EAR Estrutura Analtica de Riscos EBD Entidades de Banco de Dados eGovSS eGovernment Solues de Software (empresa fictcia da causstica) ISO International Organization for Standardization KLOC Mil linhas de cdigo LOC Linhas de cdigo MERCOSUL Mercado Comum do Cone Sul MPS-BR Melhoria de Processos de Software Brasileiro PC Personal Computer, ou Computador Pessoal PMBOK Project Management Body of Knowledgement PMC Monitoramento e Controle de Projeto PMI Project Management Institute PMP Project Management Professional PP Planejamento de Projetos PPQA Garantia da Qualidade de Processos e Produtos PSM Practical Systems Software Managment
REQM Gerenciamento de Requisitos RF Requisito Funcional ROI Retorno de Investimento SAM Gesto de Acordo com Fornecedores SEI Software Engineering Institute SEPG Grupo de Processos de Gerenciamento de Software SVN - SubVersion TI Tecnologia da Informao WBS Estrutura Analtica do Projeto
SUMRIO
1. 2. 2.1. 2.2. 2.3. 3. 3.1.
INTRODUO ............................................................................................................................ 13 CONTEXTUALIZAO .............................................................................................................. 15 PMBOK ....................................................................................................................................... 15 CMMI-DEV .................................................................................................................................. 17 PROCESSO DE IMPLANTAO DE KULPA E JOHNSON ...................................................... 21 ESTUDO DE CASO .................................................................................................................... 23 VISO GERAL ............................................................................................................................ 23
3.1.1. CASO DE NEGCIO .................................................................................................................. 24 3.1.2. VISO DA ESTRUTURA ORGANIZACIONAL DA EMPRESA .................................................. 25 3.2. O PROCESSO DE TRABALHO DAS EQUIPES DE DESENVOLVIMENTO ............................. 29
3.2.1. ANLISE QUANTITATIVA DA CARGA DE TRABALHO DAS UNIDADES ............................... 32 4. 3.1. 3.2. O PROJETO DE IMPLANTAO PARA MELHORIA DE PROCESSOS ................................ 36 PROCESSOS DAS FASES DE INICIAO E PLANEJAMENTO ............................................. 38 ENTRADAS E SADAS DA INICIAO E DO PLANEJAMENTO ............................................. 39
3.2.1. TERMO DE ABERTURA DO PROJETO .................................................................................... 39 3.2.2. DECLARAO DE TRABALHO DO PROJETO ........................................................................ 40 3.2.3. CASO DE NEGCIO .................................................................................................................. 40 3.2.4. FATORES AMBIENTAIS DA EMPRESA .................................................................................... 40 3.2.5. REGISTRO DAS PARTES INTERESSADAS............................................................................. 44 3.2.6. PLANO DE GERENCIAMENTO DO PROJETO......................................................................... 45 3.2.7. REQUISITOS DO PROJETO...................................................................................................... 45 3.2.8. PLANO DE GERENCIAMENTO DOS REQUISITOS ................................................................. 46 3.2.9. ACEITAO DOS REQUISITOS DO PROJETO ....................................................................... 46 3.2.10. 3.2.11. 3.2.12. 3.2.13. 3.2.14. 3.2.15. 3.2.16. 4. MATRIZES DE RASTREABILIDADE .................................................................................. 47 DECLARAO DE ESCOPO, WBS, CRONOGRAMA ....................................................... 47 LINHA DE BASE DE DESEMPENHO DOS CUSTOS ........................................................ 49 PLANO DE QUALIDADE E MTRICAS DE QUALIDADE .................................................. 49 PLANO DE RECURSOS HUMANOS .................................................................................. 50 PLANO DE GERENCIAMENTO DOS RISCOS .................................................................. 50 PLANILHA DE RISCOS ....................................................................................................... 51
CONSIDERAES FINAIS........................................................................................................ 52
5. 6.
REFERNCIAS .......................................................................................................................... 53 GLOSSRIO ............................................................................................................................... 55
APNDICE A TERMO DE ABERTURA DO PROJETO ................................................................... 58 APNDICE B DECLARAO DE TRABALHO DO PROJETO ...................................................... 63 APNDICE C REGISTRO DAS PARTES INTERESSADAS ............................................................ 66 APNDICE D PLANO DE GERENCIAMENTO DO PROJETO........................................................ 69 APNDICE E PLANILHA DE ACOMPANHAMENTO DO PROJETO ............................................. 79 APNDICE F REQUISITOS DO PROJETO...................................................................................... 83 APNDICE G ACEITAO DOS REQUISITOS ............................................................................ 103 APNDICE H MATRIZES DE RASTREABILIDADE ...................................................................... 107 APNDICE I PLANO DE GERENCIAMENTO DE REQUISITOS................................................... 111 APNDICE J DECLARAO DO ESCOPO DO PROJETO ......................................................... 117 APNDICE K ESTRUTURA ANALTICA DO PROJETO (WBS) ................................................... 125 APNDICE L CRONOGRAMA DO PROJETO ............................................................................... 130 APNDICE M LINHA DE BASE DE CUSTOS DO PROJETO ....................................................... 139 APNDICE N PLANO DE QUALIDADE E MTRICAS DO PROJETO ......................................... 141 APNDICE O MODELO DE INFORMAO PARA MEDIO ..................................................... 151 APNDICE P PLANO DE RECURSOS HUMANOS....................................................................... 153 APNDICE Q PLANO DE GERENCIAMENTO DOS RISCOS ...................................................... 161 APNDICE R PLANILHA DE RISCOS ........................................................................................... 169 ANEXO I PROCESSO BSICO DE SOFTWARE UNIDADE TRIBUTRIA ............................... 173
13
1.
INTRODUO
Esta pesquisa pretende mostrar que um projeto para a implantao da melhoria de
processos de desenvolvimento de software, atravs de um planejamento realizado de acordo com o Guia de Conhecimentos para Gerenciamento de Projetos (PMBOK) e concepes apresentadas para o processo de implantao do CMMI-DEV, conforme a metodologia apresentada por Kulpa e Johnson (2008), uma tarefa que exige conhecimento sobre a abordagem adotada, comprometimento, envolvimento e disponibilidade das pessoas envolvidas no projeto, principalmente daqueles que o coordenam. So exigidas destas pessoas, habilidades para motivar, treinar, orientar, sugerir tcnicas e procedimentos etc., bem como analisar os desvios que implicam na no aderncia de um processo s metas e prticas impostas pelo CMMI-DEV. O CMMI-DEV um modelo de referncia que fornece direcionamento para as prticas a serem seguidas em um processo de desenvolvimento de software. O principal objetivo foi realizar um planejamento para a construo de um processo consistente e maduro baseado nas metas e prticas do CMMI-DEV nvel 2, utilizando as recomendaes do PMBOK, focando-se na mitigao dos riscos do projeto, no cumprimento dos prazos e no alcance da qualidade dos servios a serem executados. Com isto, foi realizada a criao de um estudo de caso baseado em um cenrio tpico de processo ad hoc de trabalho e nos problemas inerentes de uma empresa fictcia que se encontra no nvel catico de maturidade em processo de desenvolvimento de software e que pretende obter a certificao CMMI-DEV nvel 2. Este trabalho objetivou tambm realizar a identificao de riscos do projeto e um planejamento para sua mitigao ou contingenciamento; a realizao de estimativas de custos e de esforo para execuo do projeto; a determinao de critrios para o sucesso do projeto; a especificao de recursos necessrios para as atividades do projeto; a criao e definio de demais produtos de trabalho que possam facilitar o planejamento e o controle do projeto etc. Entretanto, no foi objetivo: Realizar a execuo do que foi planejado para o projeto de implantao e, consequentemente, realizar anlises comparativas pr e ps-implantao;
14
Definir ou criar um processo ou uma metodologia particular de desenvolvimento de software que possa ser utilizada por uma empresa;
Realizar a anlise e desenvolver o projeto de processos ou de produto.
O planejamento para o projeto foi realizado baseando-se em uma pesquisa sobre o processo de implantao do CMMI-DEV, bem como tambm na experincia prtica de implantao seguindo uma abordagem semelhante, a Melhoria de Processos de Software Brasileiro (MPS-BR). Foi levado em considerao os problemas decorrentes do impacto da mudana de cultura organizacional, da falta de visibilidade ou m expectativa dos envolvidos, da m gesto tcnica em gerenciamento de projetos de software, da inexistncia da garantia da qualidade, dentre outros. Estes problemas levam uma equipe de desenvolvimento ao descumprimento dos prazos, ao retrabalho contnuo, ao dispndio desnecessrio de recursos oramentrios e ausncia ou baixa qualidade dos seus produtos e servios. Este trabalho est organizado da seguinte forma: Captulo 2: Contextualizao; Captulo 3: Estudo de Caso; Captulo 4: Projeto de Implantao; Capitulo 5: Consideraes Finais; Apndices: contm os artefatos para iniciao e planejamento do projeto utilizados, conforme sugeridos pelo Guia PMBOK.
15
1. CONTEXTUALIZAO
Este captulo apresenta a fundamentao terica em que est alicerado este trabalho e subdividida em sees que categorizam as abordagens utilizadas.
1.1. PMBOK
Conforme mencionado em PROJECT MANAGEMENT INSTITUTE (2009), o Guia de Conhecimento em Gerenciamento de Projetos (PMBOK) uma norma reconhecida mundialmente para o gerenciamento de projetos. O conhecimento contido neste padro evoluiu a partir das boas prticas reconhecidas de profissionais de gerenciamento de projetos que contriburam significativamente para o seu desenvolvimento. O objetivo do Guia identificar a aplicao de conhecimentos, processos, habilidades, ferramentas e tcnicas adequadas descritos em um conjunto de conhecimentos em gerenciamento de projetos. Este conjunto reconhecido amplamente e so aplicveis maioria dos projetos na maior parte do tempo e que existe um consenso em relao ao seu valor e sua utilidade (PROJECT MANAGEMENT INSTITUTE, 2009). Um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. A temporariedade indica que o projeto tem incio e fim definidos em um planejamento estabelecido previamente, no significando tambm ser de curta durao. A mesmo guia descreve que o gerenciamento de projetos aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. Ele realizado atravs da aplicao e integrao dos 42 processos agrupados logicamente abrangendo 5 grupos de processos, como se segue: Iniciao; Planejamento; Execuo; Monitoramento e controle; e, Encerramento.
16
O gerenciamento inclui a identificao de requisitos, a adaptao s diferentes necessidades e expectativas das partes interessadas medida que o projeto planejado e realizado e o balanceamento das restries conflitantes que incluem, mas no se limitam, ao escopo, qualidade, cronograma, oramento, recursos e riscos.
Escopo
Risco
Qualidade
Recursos
Cronograma
Oramento
Figura 1 - Restries
O relacionamento entre estes fatores afetam outros. Este projeto influenciar significativamente os riscos, o cronograma e o oramento, devendo o gerente de projetos se concentrar nessas restries. Deste modo, o presente trabalho atm-se a realizao das atividades das reas de processos de iniciao e planejamento, conforme aes sugeridas por HELDMAN (2009). A Figura 2 exibe a estrutura do grupo de processos de planejamento de projeto. Todos os produtos de trabalho desenvolvidos que apoiam o incio e o planejamento do projeto para melhoria de processos de desenvolvimento de software esto relacionados no captulo 3 e so apresentados nos apndices, exceto aqueles inerentes rea de processo de aquisies. Alguns planos foram elaborados junto ao plano de gerenciamento de projeto no Apndice D Plano de Gerenciamento do Projeto, outros possuem seus prprios documentos.
17
Figura 2 - Grupo de Processos de Planejamento
1.2. CMMI-DEV
O Capability Maturity Model Integration (CMMI) um modelo que guia a melhoria dos processos organizacionais. Foi desenvolvido pelo Instituto de Engenharia de Software (SEI) da Universidade Carnegie Mellon. O CMMI for Development, publicado em maro de 2002, uma especificao do modelo CMMI para a indstria de software, baseado nas melhores prticas e padres de qualidade da Engenharia de Software. Seu desenvolvimento foi influenciado por diversos fatores, dentre as quais, problemas de desenvolvimento de software comumente conhecidos, mas no
18
resolvidos, [...] solues [...] no so praticadas nos projetos de software, pois existe um gap entre o estado da arte e o estado da prtica (PESSOA, 2004, p. 15). Mencionando-se o termo qualidade, as primeiras abordagens que se referem qualidade no segmento industrial, visando aumentar a capacidade inerente de um processo a fim de produzir resultados desejados, surgiram a partir do trabalho de gerenciamento da qualidade de W. Edwards Deming, Philip B. Crosby e Joseph M. Juran, pessoas responsveis pela expanso do movimento pelo gerenciamento da qualidade e das teorias a respeito do custo da qualidade (HELDMAN, 2009, p.308). Desta forma, o modelo CMMI-DEV objetiva amadurecer um processo de desenvolvimento de software, trazendo vrios benefcios, conforme citado por Pessoa (2004): Estabelecer uma linguagem comum; Construir uma viso compartilhada; Construir um conjunto de processos e procedimentos desenvolvidos com sugestes de uma ampla participao da comunidade de software; Oferecer uma estrutura para se priorizar as aes; Estabelecer uma estrutura para se realizar avaliaes confiveis e consistentes; Auxiliar comparaes em diversas indstrias.
Ao contrrio, o mesmo autor tambm infere que um processo imaturo : Ad hoc, improvisado por profissionais e gestores; No rigorosamente seguido e o seu cumprimento no controlado; Altamente dependente dos profissionais atuais; Com baixa viso do progresso e da qualidade; Cujas funcionalidades e qualidade do produto podem ficar comprometidas para que os prazos sejam cumpridos; Arriscado do ponto de vista do uso de novas tecnologias; Com custos de manuteno excessivos; Com qualidade difcil de prever.
19
Com isto, uma organizao que possui um processo imaturo se encontra em um estado denominado catico, sendo a preveno de incndios sua nica forma de controle. O CMMI-DEV possui duas representaes. Uma denominada representao por estgios e a outra representao contnua.
Nvel 5 Nvel 4 Nvel 3 Nvel 2 Nvel 1 (caos)

Figura 3 - Representao Estagiada
A representao por estgio mais antiga e adota a ideia de realizar a implementao da melhoria de processos em representaes em nveis sequenciais conforme ilustrado na Figura 3, onde so chamados de nveis de maturidade e cada um possui um conjunto especfico de reas de processos que agrupam boas prticas. O primeiro nvel define o estado catico de uma organizao, conforme caracterizada anteriormente. A representao contnua baseada na premissa de que a organizao pode possuir alguns processos com maior e outros com menor capacidade. [...] alguns processos so bem estruturados, realizados de forma organizada, seguindo procedimentos escritos e outros so menos organizados, sem uma padronizao. Nesse caso utiliza-se o conceito de capacidade de processo (PESSOA, 2004, p. 17). Esta representao ilustrada na Figura 4.
20
5 4 Capacidade 3 2 1 Processos PP PMC REQM SAM MA
Figura 4 - Representao Contnua
O projeto de implantao do CMMI-DEV realizado com base na representao estagiada, no nvel 2 de maturidade, e visa estabelecer a execuo de prticas inerentes s reas de processos abaixo: Gesto de Requisitos (REQM), aonde estabelece prticas para gerenciamento das mudanas nos requisitos que podero ocorrer em qualquer ponto de execuo em um processo de desenvolvimento de software; Planejamento de Projeto (PP), que objetiva orientar os gerentes de projeto, ou papis equivalentes, no planejamento para o esforo, custo, oramento, recursos, riscos, qualidade etc., para um projeto de desenvolvimento de software; Monitoramento e Controle de Projeto (PMC), que proporciona um entendimento do progresso do projeto, de forma que aes corretivas apropriadas possam ser tomadas quando o desempenho do projeto desviar significativamente do plano (SOFTWARE ENGINEERING INSTITUTE, 2006); Gesto de Acordo com os Fornecedores (SAM), tem o propsito de gerenciar as aquisies realizadas para o projeto; Medio e Anlise (MA), que prov tcnicas e ferramentas necessrias para obteno de informaes relevantes para o projeto, baseando-se em medies; Garantia da Qualidade de Processo e de Produto (PPQA), que estabelece prticas necessrias de forma a garantir que os procedimentos estabelecidos para o
21
processo esto sendo executados e que o produto aderente aos padres institucionalizados de qualidade; Gesto de Configurao (CM), que estabelece e mantm a integridade dos produtos de trabalho, utilizando identificao, controle, balano e auditorias de configurao (SOFTWARE ENGINEERING INSTITUTE, 2006).
1.3. Processo de Implantao de Kulpa e Johnson

Uma implantao de sucesso deve ser realizado sob um bom planejamento utilizando um processo aplicvel e provado. Kulpa e Johnson, em Interpreting the CMMI, a Process Improvement Approach, sugerem um timo processo para implantao do CMMI dividido em quatro fases bsicas:
Set Up
Design
Pilot
Implement
Figura 5 - Processo de Implantao do CMMI-DEV
1. Set Up que estabelece o grupo para melhoria de processos e uma infraestrutura organizacional, incluindo o estabelecimento da linha de base do processo, um planejamento inicial e o estabelecimento do envolvimento e do comprometimento da organizao; 2. Design que define as polticas e os procedimentos, a identificao e a definio dos padres e dos processos; 3. Pilot que realiza o treinamento dos participantes e o teste dos procedimentos em poucas reas. Os procedimentos so atualizados, quando necessrio, baseado nos resultados dos pilotos; 4. Implement so executados os procedimentos em todos os projetos e a sua efetividade medida. Kulpa e Johnson definem em seu livro, prticas e ferramentas a serem utilizadas no processo de implantao. Com isto, foram definidas entregas baseadas na metodologia
22 proposta e so detalhadas no Apndice K Estrutura Analtica do Projeto (WBS) e no Apndice L Cronograma do Projeto.
23
2. ESTUDO DE CASO
Na falta de padres expressivos, uma nova indstria, como a de softwares, passa a depender de folclore. Tom DeMarco
Esta seo apresenta um estudo de caso que ser utilizado em todo trabalho e ser atualizado em outras sees. Este estudo de caso foi projetado para mostrar como um gerente de projetos pode aplicar seu conhecimento em gerenciamento de projetos de acordo com as prticas recomendadas pelo Guia PMBOK.
2.1. Viso geral

A eGovernment Solues de Software1 (eGovSS) uma organizao tpica com negcios voltados para o desenvolvimento de solues de software destinados informatizao de processos de trabalho de instituies pblicas dos poderes executivos municipais e estaduais, como por exemplo, prefeituras, secretarias, autarquias etc. A empresa enfrenta problemas na rea de desenvolvimento de software, causados pela m gesto das mudanas dos requisitos e das necessidades dos clientes, m organizao na execuo das tarefas, aonde geralmente realizada dentro de prazos curtos para entrega, definio precria das atribuies e responsabilidades dos recursos humanos, acompanhados do conflito e acmulo de papis, desconhecimento das causas dos altos custos despendidos, gerenciamento ad hoc dos riscos de projeto e baixa qualidade dos produtos gerados. Os procedimentos de trabalho adotados para o desenvolvimento de software so caracterizados pela execuo de tarefas baseadas na experincia de pessoas que gerenciaram atividades para a construo de produtos de software novos, de complexidade mdia que, em at certo tempo, tiveram algum sucesso, mas que na verdade, esconderam futuros problemas. A diretoria decidiu que os procedimentos de desenvolvimento de software das suas equipes devero estar aderentes s melhores prticas definidas de acordo com o Capability Maturity Model Integration for Development (CMMI-DEV) e com isto obter um selo de qualidade reconhecido internacionalmente, aps uma avaliao positiva pelo Instituto de
No presente trabalho, ser utilizada no estudo de caso uma empresa fictcia, embora possua caractersticas baseadas em empresas reais.
24
Engenharia de Software dos Estados Unidos (SEI). Esta deciso foi tomada devido s problemticas apresentadas anteriormente e a outros fatores que a influenciaram, como aqueles que dizem respeito necessidade de divulgar os servios de qualidade da empresa aos seus clientes e futuros parceiros. O objetivo desta seo apresentar a estrutura organizacional da empresa e um pequeno caso de negcio baseado no modus operandi das equipes de desenvolvimento que esto vinculadas s unidades de negcio e de apoio. Depois ser realizada uma anlise crtica dos procedimentos de trabalho adotados baseando-se nas prticas do CMMI-DEV nvel 2.
2.1.1. Caso de negcio

A necessidade que a empresa possui em reaver sua marca evidenciada nesta fatia de mercado tambm baseada na oportunidade de negcio observada a partir de uma pesquisa realizada pela empresa. Baseando-se em um caso de negcio de sucesso, apresentado no Meeting de Tecnologia 2007, realizado na cidade de Joo Pessoa, por Helena C. Bastos, gerente da Unidade de Desenvolvimento do Servio Federal de Processamento de Dados (SERPRO), houveram resultados bastantes positivos que devem ser considerados para a implantao do CMMIDEV em uma empresa. A Tabela 1: Resultados da melhoria antes e aps a implantao do CMMI, contm os resultados com indicadores que demonstram a melhoria antes e aps a implantao do CMM2 nvel 2 e CMMI nvel 3 no SERPRO:
Tabela 1: Resultados da melhoria antes e aps a implantao do CMMI
Indicador
Quantidade de homologaes at o encerramento Tempo mdio das homologaes Quantidade de erros por homologao Quantidade de erros ps-implantao do produto Custo de manutenes corretivas Entrega de sistemas no prazo Quantidade de perdas de mdulos / componentes Quantidade de erros na fase de testes
Antes
2 10 dias 380 erros 20 erros 30% 70% 10 perdas 600 erros
Aps CMM L2
1 6 dias 110 a 44 erros 10 a 5 erros 10% 100% 0 perda 200 erros
Aps CMMI L3
1 3 dias 10 erros 1 erro 0% 100% 0 perda 50 erros
CMM significa Capability Maturity Model e a antiga denominao dada ao CMMI.
25
Produtividade (pontos por funo/dia)
0,25
0,57
1
Fonte: SERPRO
Estes indicadores demonstram uma melhoria significativa nos resultados do produto e do processo de software. Consequentemente, esta melhoria implicou na grande reduo de custos e no aumento da qualidade do produto e da satisfao do cliente. Portanto, a melhoria da qualidade de processos e produtos uma oportunidade de negcio relevante e a obteno do selo de qualidade tambm impulsiona a empresa a vender seus produtos e servios para fora do pas. Apesar de o processo de melhoria ser dispendioso, levando em conta um investimento inicial que est em torno de R$ 250.000,00 (VENTURA, acesso em 18 jan. 2010), o perodo de retorno de investimento levar cerca de trs anos, isto se o projeto tiver sido concludo com sucesso em dois anos.
2.1.2. Viso da estrutura organizacional da empresa

Faz-se necessrio conhecer a estrutura organizacional da empresa, pois uma das metas de um projeto de implantao para melhoria de processos de software conhecer detalhadamente esta estrutura, facilitando posteriormente o reconhecimento das partes interessadas do projeto e a delimitao do escopo do problema. A eGovSS possui 53 colaboradores ligados diretamente em atividades de
desenvolvimento de software, sendo identificados ento de acordo com as suas funes: Trs gerentes de unidades de negcio; Trs gerentes de unidades de apoio; Vinte e cinco analistas-desenvolvedores; Dez desenvolvedores; Dez atendentes-testadores.
Estes colaboradores so distribudos pelas unidades de negcio e de apoio. A empresa tambm possui setores comuns administrao interna, como os seus prprios setores de recursos humanos, financeiro, comercial e jurdico, bem como uma presidncia e suas assessorias. Estes setores no fazem parte do escopo da aplicao do projeto para implantao da melhoria proposta por este trabalho, mas possuem partes interessadas que podero intervir
26
sobre o projeto. A presidncia patrocinar a execuo do projeto e que, consequentemente, deseja obter um feedback positivo dos resultados. Detalhando as unidades de negcios, estes so administrados por pessoas que tm atribuies especficas ao gerenciamento das atividades das equipes de desenvolvimento de software. Eles tambm gerenciam as expectativas destes clientes com relao as suas necessidades. Cada gerente de unidade de negcio responsvel por uma rea de negcio especfica: Unidade de tributao e arrecadao de recursos dos municpios; Unidade de administrao de recursos oramentrios e administrativos (patrimoniais e gesto de materiais) dos municpios; Unidade de planejamento e administrao de recursos humanos.
Existe a possibilidade de a empresa expandir o escopo de seu negcio para produtos de software que atendam ao mercado bancrio e gesto da sade pblica. Os gerentes de unidades de apoio tm atribuies especficas ao gerenciamento das atividades das seguintes unidades: Tecnologia, que unidade responsvel em garantir a disponibilizao e o funcionamento dos recursos computacionais e de rede atravs de suporte pessoal e aquisio de hardware e software; Desenvolvimento JAVA, unidade responsvel pelo desenvolvimento de produtos baseados na tecnologia e arquitetura JAVA, da Sun; Desenvolvimento .NET, unidade responsvel pelo desenvolvimento de produtos baseados na tecnologia e arquitetura .NET, da Microsoft.
Os analistas-desenvolvedores realizam a anlise das requisies dos clientes e verificam sua viabilidade para atendimento, dentro dos prazos que os clientes geralmente impem e de acordo com as restries da tecnologia empregada. Estes tambm desenvolvem cdigo para construo de software e realizam procedimentos de alta criticidade. Geralmente possuem um bom entendimento das regras de negcio para o produto e do prprio produto de software. Orientam tecnicamente novos desenvolvedores na execuo de suas atividades. Os desenvolvedores possuem uma nica atribuio de construir cdigo para o produto de software. Em algumas unidades de negcio, os analistas repassam uma pequena anlise preliminar para o desenvolvedor, indicando quais componentes devem ser alterados e como a
27
funcionalidade
dever
ser
alterada
para
atingir
um
determinado
propsito.
Os
desenvolvedores iro, aos poucos, adquirindo conhecimento acerca das regras de negcio. Os desenvolvedores da unidade de apoio JAVA tambm realizam testes unitrios de componentes de cdigo. Os atendentes-testadores possuem duas atribuies distintas: Suporte ao cliente. O propsito orientar o cliente no uso do produto de software, coletar as requisies dos clientes, oferecer suporte tcnico presencial no local de trabalho do cliente, realizar treinamentos e apoiar as atividades de suporte em implantao do produto. Em algumas unidades de negcio existe uma pessoa que tem uma experincia elevada em atendimento ao cliente, possui todo o conhecimento das regras de negcio que esto inseridos no produto de software. Isto faz desta pessoa um gerente de atendimento; Testes. Os testes so realizados ao final do desenvolvimento aps as entregas dos componentes de software pelos analistas-desenvolvedores e pelos desenvolvedores. Os testes podem ser realizados em um nico componente ou conjunto destes, como tambm aps a integrao destes componentes em um nico produto.
O setor comercial responsvel em realizar anlise mercadolgica, verificando oportunidades atravs de editais das licitaes publicadas pelas administraes municipais e estaduais distribudas pelo pas. Este setor possui colaboradores chamados de gestores de contrato, responsveis em gerenciar diretamente as expectativas dos clientes com relao as suas necessidades. Os gestores de contrato so alocados em um ou mais clientes, podendo residir na cidade destes ou no. apresentado na Figura 6 - Estrutura Organizacional da eGovSS, o organograma da empresa. Os retngulos com texto em itlico representam os papis assumidos pelos colaboradores:
28
Presidncia
Recursos humanos
Financeiro
Comercial
Jurdico
Tecnologia
Gerente da Unidade de Apoio Unidade Oramentria e Administrativa Unidade Recursos Humanos
Unidade Tributria
Demais unidades de apoio
Gerente da Unidade
Gerente da Unidade
Gerente da Unidade
Desenvolvimento JAVA
Desenvolvimento .NET
Analista de Sistemas
Gerente da Unidade de Apoio
Gerente da Unidade de Apoio
Desenvolvedor
Desenvolvedor
Desenvolvedor
AtendenteTestador
AtendenteTestador
AtendenteTestador
Desenvolvedores
Desenvolvedores
Testadores
Testadores
Figura 6 - Estrutura Organizacional da eGovSS
Observando a Figura 6, verifica-se que a organizao do tipo organizao funcional, centradas em especializaes e agrupadas por funo (HELDMAN, 2009, p. 16). Muitas das atribuies de um gerente de projetos so empregadas ao gerente da unidade e a assessoria tcnica da presidncia.
29
2.2. O processo de trabalho das equipes de desenvolvimento

Os procedimentos para anlise, desenvolvimento e testes de software foram construdos baseados no entendimento dos recursos mais antigos de cada equipe, sendo tais procedimentos baseados em operaes de servio. O processo de trabalho desta empresa pode ser modelado e representado atravs de fluxogramas bsicos, conforme ilustrado no Anexo I Processo Bsico de Software . A alta gerncia atribui a cada gerente de unidade total independncia no gerenciamento de seus recursos, no modus operandi para realizao de atividades de desenvolvimento de software e no atendimento ao cliente, bastando somente apresentarem os resultados para a alta gesto da empresa, que busca obter a satisfao do cliente e um retorno financeiro aceitvel. Para a alta gesto, a descentralizao da tomada de decises tcnicas mais generalizadas facilitou o gerenciamento de outras atividades e diminuiu a sua prpria sobrecarga. Para a equipe tcnica, isto trouxe benefcios aparentes, dentre um deles, a realizao da tomada de deciso acerca dos mtodos e tecnologias que poderiam ser utilizadas por cada equipe. Contudo, realizando uma melhor anlise, a total independncia das equipes no benfica para o negcio, conforme ser descrito posteriormente. Assim, para cada unidade, foram modelados cinco processos de desenvolvimento totalmente baseado em operaes: 1) Unidade Tributria. No Anexo I foi inserida a modelagem do processo bsico de software baseado em operaes para a unidade. As operaes realizadas do nfase ao recebimento das solicitaes de servios encaminhadas pelos clientes, o que ocorre em grande volume. Neste processo tambm dada nfase anlise tcnica de primeiro nvel, aonde so verificadas o entendimento da necessidade do cliente e a viabilidade tcnica em atend-lo. Sendo vivel, a solicitao de servio ser includa na prxima entrega do produto. Somente testes de usabilidade e operacionalizao so realizados. A ferramenta de controle de verso utilizada somente para armazenar cdigo-fonte estvel aps os testes. Por fim, gerado um empacotamento dos componentes do produto, chamada pela equipe de release, que depois disponibilizada ao cliente. 2) Unidade Oramentria e Administrativa. Esta unidade dividida em duas subunidades que so responsveis por desenvolver software para dois segmentos de negcios diferentes. Cada subunidade possui seus prprios recursos especializados,
30
sendo que uma equipe no interfere sobre as atividades da outra, apesar de possurem o mesmo gerente. Em atividades relacionadas anlise tcnica de primeiro nvel, a equipe da subunidade Oramentria constri, quando a solicitao no urgente, um artefato que contm alguns procedimentos e descries textuais tcnicas para realizao da implementao da solicitao, o que na equipe da subunidade Administrativa no ocorre. A distribuio de tarefas realizada por uma ferramenta simples, construda por desenvolvedores da prpria empresa, aonde so gerenciadas de forma semelhante a trmites de processos em entidades pblicas. A ferramenta de controle de verso utilizada somente para armazenar cdigo-fonte, com o objetivo de facilitar o gerenciamento de acesso concorrente aos arquivos do repositrio, baseando-se no mtodo semelhante ao controle travar-alterar-destravar, provocando o no paralelismo das atividades de desenvolvimento. Somente testes de usabilidade e operacionalizao so realizados. E, semelhante equipe da unidade Tributria, gerado um empacotamento dos componentes do produto, chamada pela equipe de release, que depois disponibilizada ao cliente. Como pode ser observado no modelo do processo baseado em operaes em anexo, as atividades so bem detalhadas. 3) Unidade Recursos Humanos. Igualmente, o processo baseado em operaes e possui atividades semelhantes aos modelados nos processos anteriores, diferenciando apenas na execuo de atividades de gerenciamento parcial de configurao, onde a utilizao da ferramenta de controle de verso melhor realizada se comparada com outras equipes. tambm gerado um documento de verso aonde so descritos as alteraes realizadas no produto e, depois, so enviadas ao cliente. 4) Unidade de Apoio Desenvolvimento JAVA. Os procedimentos de trabalho tem sequencialidade baseada simplesmente na recepo da solicitao de mudana, desenvolvimento, teste e entrega, no havendo quaisquer anlises formais. As atividades so gerenciadas pela passagem das solicitaes atravs de trmites e modificaes de status de cada solicitao. Existe a tentativa de organizar um processo baseado em projetos, mas a equipe ainda no havia obtido apoio da organizao. 5) Unidade de Apoio Desenvolvimento .NET. A equipe montada nova e ainda no realizou quaisquer procedimentos para desenvolvimento de software.
31
Em geral, os procedimentos executados para o desenvolvimento de software so realizados de maneira um pouco diferente para cada equipe. Algumas ferramentas, componentes de desenvolvimento, procedimentos, artefatos, termos tcnicos utilizados, atribuies e responsabilidades dos papis, so criados e utilizados diferentemente em cada equipe, tornando cada unidade uma ilha, constituindo empresas distintas dentro de uma mesma organizao. Muitos problemas vm ocorrendo por este modelo de gesto,
implicando algumas consequncias negativas no processo de negcio, pois: 1. Todos os produtos de software desenvolvidos pelas equipes devem interagir entre si, o que vem ocorrendo de maneira muito insatisfatria, causando aborrecimentos equipe tcnica; 2. As mudanas dos requisitos dos produtos no so gerenciadas efetivamente. A mudana em uma caracterstica ou funcionalidade de um produto afetam outros produtos, gerando bugs, retrabalho e insatisfao do cliente; 3. A comunicao entre equipes precria. O levantamento dos requisitos no realizado de forma a obter entendimento completo e no ambguo; 4. As novas equipes de desenvolvimento tendem a enfrentar os mesmos problemas descritos anteriormente; dentre outros. Mesmo assim, existe a falsa crena de que se pode gerenciar uma equipe com todos os problemas descritos neste trabalho e ainda assim satisfazer o cliente e entregando software com qualidade. implcito dizer que:
Os gerentes com responsabilidade sobre o software, [...] esto frequentemente sob presso para obedecer a oramentos, manter cronogramas no prazo e melhorar a qualidade. Como uma pessoa que est se afogando e se agarra em um pedao de madeira, um gerente de software frequentemente se agarra crena em um mito de software, se isso puder diminuir a presso, ainda que temporariamente. (PRESSMAN, 2006, p. 10).
Essa realidade reflete no somente nesta organizao, mas a maioria das organizaes no mundo confiam em mitos que so crenas sobre softwares e sobre o processo usado para constru-los (PRESSMAN, 2006, p. 10). As unidades organizacionais e de apoio possuem quantidade restritiva de recursos humanos para codificao. Tendo em vista o tamanho dos produtos de software a serem mantidos e a quantidade de solicitaes de manuteno enviadas pelos clientes, a qualidade do produto diminui consideravelmente.
32
2.2.1. Anlise quantitativa da carga de trabalho das unidades

Realizando uma anlise de dados levantados por um perodo de trs meses, constataramse outros problemas: 1. O tamanho dos produtos de software e a quantidade de solicitaes para manuteno exige melhor gerenciamento de mudanas. Na Tabela 2, as unidades organizacionais que possuem os maiores produtos em manuteno so a unidade Recursos Humanos e a unidade Tributria.
Tabela 2: Quantidade de linhas de cdigo por unidade organizacional
Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Mdia
Quantidade LOC 451.623 1.545.253 455.930 696.522 3.149.328
Quantidade EBD 923 2.189 566 1.666 5.344
verificado que: a. A primeira unidade que detm o maior produto possui dois subprodutos semelhantes, mas que so mantidos separadamente para clientes distintos. Um dos subprodutos mais estvel do que o outro e geralmente as alteraes solicitadas pelos clientes so replicadas uma na outra. A verso estvel foi desenvolvida para atender as necessidades de um cliente em potencial. O objetivo da equipe migrar as caractersticas e funcionalidades de um produto para o outro e, enquanto isto no ocorre, por um longo perodo de tempo, os dois produtos so mantidos concorrentemente. Por este motivo a equipe passa por grandes problemas, apesar de ser experiente em escrever software; b. A segunda unidade possui uma verso de trabalho mais estvel e uma equipe bem experiente na rea de desenvolvimento. Porm, seus procedimentos baseiam ainda em processos ad hoc e que, com o projeto de melhoria, poder ganhar melhor desempenho no atendimento s mudanas dos produtos de software;
33
2. A quantidade de desenvolvedores alocados para manuteno de software por linha de cdigo baixa. O acmulo de papis interfere na produtividade e na qualidade do produto. Realizando a anlise de outros dados levantados, verificou-se: a. Na Tabela 3, a quantidade de desenvolvedores mais baixa observada na equipe da subunidade Administrativa. A alocao mdia dos recursos para atividades de desenvolvimento de 70% para um produto com cerca de 450 mil linhas de cdigo (KLOC), resultando em 225 KLOC/recurso. De acordo com a Tabela 4, esta equipe tambm a que realiza o maior esforo na manuteno de entidades de banco de dados (EBD), como manuteno de tabelas e procedimentos armazenados. O maior tempo da equipe gasto com escrita de linha de cdigo e realizam, por vezes, atividades sob horas extras que so pagas pela empresa na forma de banco de horas. Mesmo assim, observando os dados da Tabela 5, a quantidade de solicitaes no atendidas em trs meses supera a quantidade de solicitaes atendidas, onde apenas 36% das solicitaes registradas so entregues. Isto tem causado cansao fsico e desmotivao da equipe para garantir um software com melhor qualidade. Na Tabela 6, observa-se que em trs meses, um desenvolvedor responsvel por realizar 146 alteraes, sendo que somente 52 delas so atendidas e 94 no so atendidas.
Tabela 3: Quantidade de recursos humanos e alocao para produo de linha de cdigo
Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Mdia
Quantidade de desenvolvedores 2 5 5 5
Alocao mdia desenvolvimento 70% 57% 63% 79% 67,1%
b. A equipe da unidade e Recursos Humanos possui uma situao mais alarmante, pois detm a maior responsabilidade em manter um grande produto, com cerca de 300 KLOC/recurso.
Tabela 4: Quantidade de linhas de cdigo e entidades de banco de dados por desenvolvedor.
Unidade Organizacional Administrativo
LOC/recurso 225.811
EBD/recurso 461
34
Recursos Humanos Oramentrio Tributao Totais
309.050 91.050 139.304 765.215
437 113 333 1.344
De acordo com a Tabela 5, 93% das solicitaes registradas so atendidas pela equipe. importante salientar que esse grande nmero de solicitaes atendidas em trs meses no implica na entrega de produto com qualidade. Sabe-se que muitas dessas solicitaes retornam com outros bugs. Isto tambm ocorre devido a outros problemas que a equipe vem enfrentando, citando mais alguns: 1) Os prazos para entrega geralmente so curtos devido necessidade do produto gerar mensalmente a folha de pagamento de centenas de funcionrios das entidades pblicas. Isto causa o aumento da probabilidade de entregar produtos com outros bugs; 2) O produto contm muito cdigo inutilizvel; 3) Apesar de a equipe ter boa experincia na codificao de software, eles no tm boa expectativa para o futuro do produto. A equipe imagina que a tendncia de o produto no ser mais manutenvel e, desta forma, ser inutilizvel; 4) O tempo de alocao mdia para codificao a mais baixa. Muitos desenvolvedores assumem outros papis, como realizar suporte diretamente no estabelecimento do cliente; 5) A insatisfao dos clientes tem aumentado consideravelmente, levando estes a considerar a aquisio de outro fornecedor para o software; 6) A equipe tambm no tem experincia no gerenciamento de mudanas; etc.
Tabela 5: Indicadores de atendimento das solicitaes de manuteno
Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Totais
Registradas 293 725 239 438 1.695
Atendidas 105 675 170 391 1.341
No atendidas 188 50 69 47 354
% concluda 36% 93% 71% 89% 72%
35
Tabela 6: Solicitaes registradas, atendidas e no atendidas por desenvolvedor.
Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Totais
Solicitaes registradas 146,5 145,0 47,8 87,6 426,9
Solicitaes atendidas 52,5 135,0 34,0 78,2 299,7
Solicitaes no atendidas 94,0 10,0 13,9 9,4 127,3
De acordo com a exposio das caractersticas gerais da empresa e dos problemas descritos no estudo de caso, podem-se incluir: 1. Alta rotatividade de recursos experientes tem contribudo negativamente para o engajamento dos novatos aos procedimentos. Quando estas pessoas so transferidas ou saem da organizao, esta sofre. Ainda assim visvel a ideia de que um bom investimento em recursos humanos desnecessrio, o que prova a imaturidade na gesto de recursos humanos; 2. 3. Equipes que compem os projetos so pequenas; Existncia de processos ad hoc (processos que as pessoas que fazem o trabalho tm criado por si prprias para realizar suas tarefas). Contam com os feitos heroicos das pessoas; 4. 5. 6. Realizao frequente de trabalhos redundantes; Pessoas no compartilham seus mtodos com a organizao; Algumas abordagens so contrrias em realmente fazer a organizao funcionar mais efetivamente. Os resultados so mais retrabalhos, esperas e frustraes.
36
3. O PROJETO DE IMPLANTAO PARA MELHORIA DE PROCESSOS

O processo de implantao utilizado no planejamento para implantao do CMMI-DEV sobre a organizao fictcia do nosso estudo de caso embasado no trabalho de Kulpa e Johnson (2008). Foram realizadas algumas adequaes aos procedimentos para implantao, e de acordo com uma experincia vivida em implantao do MPS-BR em uma empresa de desenvolvimento de software. Muitas dvidas ocorrem antes do processo de implantao de uma abordagem inicial baseada em CMMI-DEV nvel 2 ou MPS.BR nvel G e F. Quando um processo como este divulgado em uma organizao, muitas indagaes surgem e partem de pessoas de vrias reas ou nveis organizacionais. Eis uma pequena lista com suas respectivas respostas: 1. Ser que a implantao desta abordagem realmente trar algum benefcio para nossa organizao ou equipe? Resposta: cada rea de processo implementada em uma organizao traz uma srie de benefcios para uma equipe e, consequentemente, para uma organizao. Em planejamento, monitoramento e controle de projetos, por exemplo, obtida uma viso controlada do que ser e do que est sendo realizado. uma viso, primariamente, do futuro, depois do presente e do passado, sobre informaes do esforo de cada membro da equipe na execuo de suas atividades, dos custos despendidos, dos prazos incorridos, dos riscos que afetaro ou afetam o projeto de maneira positiva e negativa, e uma infinidade de outras informaes que auxiliaro o gerente na efetiva tomada de decises. Tambm trar uma viso geral e/ou detalhada das informaes de custos sobre o andamento de um conjunto de projetos ou portflios de projetos, levando a alta gerncia a tratar assuntos relativos a anlise de custo-benefcio da iniciao ou continuidade destes projetos. A gerncia de mudanas dos requisitos permitir uma efetiva gesto dos requisitos volteis que surgem em qualquer ponto do processo de desenvolvimento de software e estabelece mecanismos para rastreabilidade entre produtos de trabalho, facilitando a gesto para alocao de atividades baseadas em requisitos interdependentes. Estabelecem tambm a delimitao do escopo do projeto e a certificao por parte do cliente sobre a aceitao do que ser desenvolvido, baseando-se tambm em caractersticas como clareza, compreensibilidade, completude, testabilidade etc. dos requisitos. Estas
37
prticas e muitas outras auxiliam bastante em aes contra ao retrabalho, evitando com isto o custo elevado de manuteno. 2. A institucionalizao de um processo baseado em CMMI ou MPS.BR trar algum ganho em termos de velocidade sobre as atividades existentes? Resposta: quase nunca a velocidade das atividades que sos executadas para atendimento das necessidades dos clientes sob curtos prazos so indcios de que o produto de software entregue de qualidade. O retrabalho gerado sobre a implementao de um requisito o principal indcio de m qualidade de um produto e este retrabalho dificilmente enxergado sem uma efetiva gerncia. Em Engenharia de Software, imprescindvel que uma boa elicitao, anlise e projeto de requisitos seja bem realizada, coisa que, infelizmente, so inaceitveis para muitos clientes e, pior ainda, negligenciados pelos prprios analistas de sistemas e/ou desenvolvedores. Em termos de gerenciamento, que o foco dos primeiros nveis das abordagens mencionadas anteriormente, a velocidade ganha com a diminuio e extino do retrabalho. 3. Estas documentaes ou procedimentos no enrijecem nosso trabalho? Resposta: depende do projeto e da tecnologia empregada para execuo do processo de desenvolvimento de software. Existem projetos que exigem um maior controle sobre os procedimentos adotados, considerando que vrios detalhes sejam documentados e armazenados para referncia futura, principalmente em projetos de alta criticidade ou projetos cientficos. Projetos pequenos e de manutenes regulares, considerando sua baixa complexidade, no necessitam ser excessivamente documentados. Todavia, se h necessidade de muita ou pouca documentao, e se nenhum software que permita agilizar o processo de documentao no utilizado, certamente haver o enrijecimento do processo. 4. necessrio realizar gerncia dos custos em projetos de manuteno? Resposta: a realizao do gerenciamento de custos imprescindvel para uma boa gesto dos recursos disponibilizados para o projeto. Acontece que muitos gerentes no desejam revelar o andamento dos custos em um processo inicial de implantao, pois estas informaes revelam muitas vezes uma fraqueza at ento desconhecida pela alta gesto. Uma verdadeira anlise de custos poder revelar que a empresa gasta mais para manter uma equipe de desenvolvimento do que deveria. Este tipo de informao muito sensvel para a alta gerncia e poder acarretar em tomadas de decises precipitadas por parte desta, que geralmente no possui conhecimento ou
38
simplesmente no deseja entender que uma equipe de desenvolvimento de software precisar de tempo para poder atender as suas expectativas. O tempo visvel de retorno do investimento aplicado melhoria de processos algo que gira em torno de alguns meses. Muitas vezes necessria a realizao de campanhas de esclarecimentos, treinamentos e participao efetiva nos novos processos (PESSOA, p. 26, 2004). Isto se torna uma prtica comum e necessrio que a coordenao e demais envolvidos do projeto da melhoria tenha tempo totalmente disponvel para realizao de suporte e esclarecimento para as dvidas. Muitas vezes necessria a realizao em conjunto ou in loco das prticas abordadas no novo processo. Outra coisa bastante necessria que a coordenao tenha habilidade para incentivar e motivar as equipes para a realizao das novas atividades. O objetivo contingenciar um risco inerente: a desmotivao das pessoas, que causado por vrios fatores, dentre os principais, primeiramente o desconhecimento da melhoria e depois o descontentamento dos recursos com a prpria organizao. O planejamento do projeto de implantao foi realizado baseando-se nas prticas sugeridas pelo Guia PMBOK. Desta forma, para cada fase do planejamento foram construdos vrios artefatos que so explicados nas prximas sesses.
4.1 Processos das fases de iniciao e planejamento

Os processos das fases de iniciao e planejamento para o projeto de implantao so baseados nas prticas recomendadas do Guia PMBOK. A contextualizao dessas prticas em um estudo de caso facilita o seu entendimento prtico e, por este simples motivo, estes processos sero caracterizados pela adoo de prticas com um alto nvel de controle. Um processo controlado tem a caracterstica de parecer enrijecer a execuo das atividades. Contudo, estes procedimentos sero necessrios para obter um conhecimento mais aprofundado das tcnicas e ferramentas que esto descritos no Guia. Para a fase de iniciao, as seguintes entradas e sadas foram elaboradas: 1. 2. 3. 4. Termo de abertura de projeto; Declarao de trabalho do projeto; Caso de negcio; Organizao dos fatores ambientais da empresa;
39
5. 6.
Organizao de alguns ativos de processos organizacionais; Registro das partes interessadas.
Para a fase de planejamento, as seguintes entradas e sadas foram elaboradas: 1. 2. 3. 4. 5. 6. 7. 8. 9. Plano de gerenciamento de projeto; Planilha de acompanhamento de projeto; Plano de gerenciamento de requisitos; Requisitos de projeto; Aceitao de requisitos; Matrizes de rastreabilidade; Declarao de escopo do projeto; Estrutura analtica do projeto (WBS); Cronograma do projeto;
10. Linha de base de desempenho dos custos; 11. Plano de qualidade e mtricas de qualidade; 12. Plano de recursos humanos; 13. Plano de gerenciamento dos riscos; 14. Planilha de riscos. Eles sero descritos nas sees a seguir.
4.2. Entradas e sadas da iniciao e do planejamento

Esta seo discorre sobre todas as entradas e sadas utilizadas para as fases de iniciao e planejamento para um projeto de implantao do CMMI-DEV nvel 2 e seu contedo se baseia no estudo de caso apresentado.
4.2.1. Termo de abertura do projeto

O termo de abertura do projeto determina o propsito e a justificativa, os objetivos, requisitos gerais, descrio e riscos iniciais do projeto, bem como estabelece um cronograma
40
de marcos e um resumo do oramento. Tambm oficializa as pessoas responsveis pelo gerenciamento do projeto. A lista dos requisitos dos interessados possui alguma tendncia inteno para estipulao dos valores oramentrios, ROI e de prazos. Estes valores foram baseados em aplicaes empricas baseadas na literatura e casos reais de outras empresas. O prazo de dois anos e meio o normal, levando em considerao a realizao do desenvolvimento dos sistemas de apoio e a realizao de treinamentos. O termo de abertura encontra-se no Apndice A deste trabalho.
4.2.2. Declarao de trabalho do projeto

A declarao de trabalho do projeto descreve o produto, servio ou resultado que deve ser produzido pelo projeto (HELDMAN, 2009). relevante observar na declarao de trabalho o que fio descrito na necessidade de negcio e no resumo do planejamento estratgico para o binio 2010/2011. A reestruturao dos procedimentos de servios bases est includa neste planejamento e dever ser levado em considerao como fator de sucesso para a organizao. A melhoria no processo de desenvolvimento dever trazer benefcios tangveis para a mesma. Esta declarao est disponvel no Apndice B deste trabalho.
4.2.3. Caso de negcio

Segundo o Guia PMBOK, um caso de negcio ou business case fornece informaes necessrias do ponto de vista de um negcio, para determinar se o projeto justifica ou no o investimento (PROJECT MANAGEMENT INSTITUTE, 2009). Uma pequena descrio sobre o caso de negcio foi feita na seo Caso de negcio deste trabalho.
4.2.4. Fatores ambientais da empresa

Fatores ambientais dizem respeito a fatores externos ao projeto que causam (ou podem causar) influncia significativa em seu sucesso (HELDMAN, 2009, p.69) e servem de entrada para vrios processos do Guia. Desta forma, os fatores ambientais desta empresa so listados nas prximas subsees.
41
Cultura, estrutura e processos organizacionais A cultura da empresa baseada em atitudes e hbitos oriundos da experincia vivida pelos administradores e donos da empresa desde a poca que eram empreendedores iniciantes do negcio. No pice da estrutura organizacional (Figura 6) detalhado na seo Viso da estrutura organizacional da empresa, a alta gerncia composta por membros familiares que, em sua maioria, no tem domnio das tcnicas de administrao de empresas, conforme so ensinados nas instituies de ensino superior do pas. Este tipo de gesto dificulta a aplicao das prticas que devem ser realizadas pelos gerentes de projetos. Embora este papel possa ser delegado a algum de confiana, ter nvel de autoridade mediana, o que influenciar os projetos. A empresa no possui processo organizacional maduro, sendo caracterizado por se encontrar no nvel 1 do CMMI, chamado de estgio inicial da maturidade ou caos. Ativos de processos organizacionais A empresa no possui polticas, instrues, planos, abordagens ou padres formais que determinam a conduo do trabalho. Algumas informaes histricas podem ser obtidas atravs de relatos de colaboradores antigos que mencionaram dois acontecimentos que so relevantes para identificao de riscos para este projeto: 1. Houve na empresa a aquisio de um selo de qualidade baseada em uma das normas ISO para gesto de servios, como terceirizao e atendimento ao cliente. No houve constncia dos colaboradores da empresa na observncia das prticas recomendadas pela norma. Desta forma, o reconhecimento foi esquecido; 2. Igualmente, houve na empresa o incio de trabalhos baseados na melhoria de processos, seguindo abordagem desconhecida. As atividades destes trabalhos no foram concludas. O padro a ser adotado para o projeto de implantao ser baseado nas metas e prticas descritas no Capability Maturity Model Integration for Development (CMMI-DEV) v 1.2, nvel 2 de maturidade. Infraestrutura Referindo-se as instalaes e equipamentos da organizao, os recursos que sero utilizados para o projeto incluem:
42
1. Instalaes: a. 6 salas climatizadas para realizao de atividades de desenvolvimento de software; b. 1 sala de reunies que comportam cerca de 40 pessoas sentadas; 2. Equipamentos: a. 60 computadores padro PC com acesso Internet para usurios; b. 10 computadores servidores; c. 2 datashows; d. Terminais telefnicos para cada sala; 3. Software a. b. c. d. e. f. g. h. i. j. k. l. m. n. o. p. q. Borland Delphi, 50 licenas; CollabNet SVN Server; Tortoise SVN; Eclipse; Enterprise Architech, uma licena corporativa; Microsoft Communications Server, uma licena corporativa; Microsoft Excel, uma licena corporativa; Microsoft PowerPoint, uma licena corporativa; Microsoft Project Server, uma licena; Microsoft Project, 10 licenas; Microsoft SharePoint Services Server, uma licena; Microsoft SQL Server, uma licena corporativa; Microsoft Visio, 2 licenas; Microsoft Visual Studio Team Edition, uma licena corporativa; Microsoft Word, uma licena corporativa; Outros componentes para desenvolvimento de software; Sistema Operacional Windows Server, uma licena corporativa; Sistema Operacional Windows, uma licena corporativa;
Recursos humanos A quantidade de recursos humanos, bem como suas atribuies, esto descritos na seo Viso da estrutura organizacional da empresa deste trabalho. Ningum possui experincias com as prticas recomendadas pelo CMMI-DEV. A concluso do trabalho do projeto depender bastante da absoro de novo conhecimento e execuo prtica pelos envolvidos com o projeto.
43
Dentre os recursos disponveis, duas pessoas sero realocadas para assumirem o papel temporrio de coordenadores do projeto. Suas atribuies e responsabilidades so: Gerenciar o projeto de melhoria de processos. Desta forma, iro realizar juntamente com a consultoria o planejamento. Realizar o acompanhamento dirio das atividades do projeto, esclarecendo dvidas e incentivando as equipes; Preparar entradas e sadas necessrias ao cumprimento das atividades; Participar de treinamentos especficos; Treinar e orientar as equipes envolvidas no projeto; Participar de reunies com a consultoria; Solicitar recursos alta gerncia; Relatar desempenho, atividades e eventuais problemas consultoria e a alta gerncia; etc. Um recurso alocado para o projeto de melhoria de processo como coordenadora ter o nome de Ana Beatriz3, pessoa experiente na rea de gerenciamento de projetos, certificada pelo PMI como PMP e professora da graduao na disciplina de Engenharia de Software. Administrao de pessoal No existem instrues formais para contrao de pessoal tcnico. A empresa tem investido em treinamentos e incentiva a profissionalizao dos seus colaboradores promovendo a realocao em horrios flexveis. As avaliaes de desempenho so informais e se baseiam em cumprimento de prazos para o atendimento ao cliente. Existe um plano de cargos e salrios definidos pela empresa. Segue um resumo do quadro de salrios e cargos funcionais.
Tabela 7: Plano resumido de cargos e salrios da empresa
Cargo funcional
Salrio bruto CLT Jnior
Salrio bruto CLT Pleno
Salrio bruto CLT Snior
O nome para o recurso fictcio. Qualquer semelhana com a estria ser mera coincidncia.
44
Administrador Gerente Contabilista Engenheiro de Software Analista de Suporte
R$ 2.300,00 R$ 1.800,00 R$ 1.800,00 R$ 1.500,00
R$ 4.200,00 R$ 3.500,00 R$ 3.000,00 R$ 3.300,00 R$ 2.850,00
R$ 7.200,00 R$ 5.000,00 R$ 4.500,00 R$ 4.800,00 R$ 4.400,00
Incentivo profissionalizao
Especializao na rea 15%
Mestrado na rea 30%
Doutorado na rea 40%
Tolerncia aos riscos das partes interessadas Para este projeto, a tolerncia aos riscos baixa. A alta gesto considera que, de acordo com os casos de negcio expostos, ela tem condies suficientes para que o projeto seja executado com sucesso. Enfatiza-se que eles no conhecem todos os riscos inerentes e atribuem as responsabilidades de sucesso ou insucesso aos coordenadores do projeto. Canais de comunicao Os canais de comunicao comuns que so estabelecidos pela organizao so o telefone, email e sites internos.
4.2.5. Registro das partes interessadas

As partes interessadas foram identificadas baseando-se na anlise e na opinio especializada atravs de entrevistas pessoais e reunies informais. Foram coletadas informaes sobre a denominao do papel de cada um na organizao, com o objetivo de auxiliar na anlise do impacto ou suporte que cada parte interessada poder gerar para o projeto, bem como sua influncia sobre outras partes interessadas; o cargo funcional definido contratualmente; o seu relacionamento com a instituio, se interno ou externo; e outras informaes necessrias para auxiliar na composio de dados para comunicao, como telefone e email. Outro dado substancial para composio do registro das partes interessadas do projeto a descrio das suas expectativas. As expectativas das partes interessadas com nveis de influncia e impacto relevantes devem ser gerenciadas efetivamente, com o objetivo de garantir apoio e comprometimento com o projeto.
45
Para este projeto, a principal parte interessada identificada foi a do patrocinador. Sua influncia bastante significativa, j que suas decises podero beneficiar ou ocasionar interferncias ao projeto e, inclusive, influenciar as decises de outras partes interessadas relevantes. A consultoria tambm exerce alta influncia, pois a maioria das decises tcnicas so tomadas levando em considerao a sua opinio. O registro das partes interessadas para este projeto poder ser encontrado no Apndice C Registro das Partes Interessadas.
4.2.6. Plano de Gerenciamento do Projeto

O plano de gerenciamento do projeto detm informaes sobre a definio, coordenao e integrao de todos os outros planos auxiliares. Resumidamente rene informaes sobre a viso geral, finalidade, objetivo e escopo do projeto, bem como realizado o planejamento para gerenciamento dos requisitos, do cronograma, dos riscos, dos recursos, da qualidade etc. Para este projeto, algumas informaes relevantes sobre gerenciamento foram dispostas em artefatos separados. So eles: Plano de gerenciamento de requisitos; Plano de qualidade; Plano de recursos humanos; Plano de gerenciamento dos riscos.
Outras informaes relevantes esto no prprio plano de gerenciamento do projeto. Observaes relevantes adicionais sobre os produtos de trabalho gerados para o planejamento deste projeto sero descritos nas prximas sees. O plano de gerenciamento deste projeto encontra-se no Apndice D Plano de Gerenciamento do Projeto. A planilha de acompanhamento encontra-se em Apndice E Planilha de Acompanhamento do Projeto.
4.2.7. Requisitos do Projeto

De acordo com Kim Heldman, os requisitos funcionais de projetos que no esto relacionados com a execuo do desenvolvimento de software em si, poderiam descrever especificaes (HELDMAN, 2009, p. 106). Desta forma, os requisitos funcionais para o projeto especificam os objetivos a serem alcanados por cada entregvel, metas e prticas
46
especficas definidas em cada rea de processo do CMMI-DEV nvel 2. Estes requisitos no definem como as aes devero ser realizadas, mas quais os objetivos devero ser atingidos. O escopo negativo para este projeto define somente a no aplicao de metodologias geis ao processo de desenvolvimento. Estas e outras abordagens podero ser adaptadas ao projeto em futuros trabalhos acadmicos. Os critrios para aceitao dos requisitos devero ser evidenciados no documento de Apndice G Aceitao dos Requisitos.
4.2.8. Plano de gerenciamento dos requisitos

A finalidade do plano de gerenciamento de requisitos documentar como os requisitos sero analisados, documentados e gerenciados do incio ao fim do projeto. descrito no documento que o levantamento dos requisitos baseia-se na anlise das metas e prticas sugeridas pelo CMMI-DEV nvel 2 de maturidade e que todas as mudanas no projeto sero aceitas levando-se em considerao os resultados das avaliaes de riscos, impacto e viabilidade tcnica, oramentria, de esforo e de atendimento aos prazos. Ser confirmada aps a aceitao formal no documento de aceitao de requisitos. Foi definida tambm um prazo para resposta a aceitao dos requisitos e de suas mudanas, visando contingenciar riscos inerentes a baixa velocidade de resposta das partes interessadas e estabelecer a agilidade do andamento do projeto. Este plano poder ser encontrado no Apndice I Plano de Gerenciamento de Requisitos.
4.2.9. Aceitao dos Requisitos do Projeto

A aceitao dos requisitos iniciais do projeto ser evidenciada em uma planilha simples, aonde as partes interessadas podero validar a completude, a clareza e o entendimento de suas necessidades. Para o gerenciamento das mudanas, este mesmo documento poder ser utilizado, bastando evidenciar no campo referente s observaes que o requisito de mudana de escopo. As aceitaes s podero ser firmadas pelas partes interessadas constantes na planilha que descreve as partes interessadas do projeto. O artefato poder ser encontrado no Apndice G Aceitao dos Requisitos.
47
4.2.10. Matrizes de Rastreabilidade

A abordagem adotada para a rastreabilidade neste definida como um mecanismo que facilite identificar quais so os itens que possuem vinculo com outros itens cujas mudanas podero influenciar um no outro. Inicialmente, a rastreabilidade ser mantida entre os requisitos funcionais e no funcionais. Observa-se no Apndice H Matrizes de Rastreabilidade, que os vrios requisitos foram vinculados a outros requisitos utilizando-se uma matriz. Qualquer mudana no requisito RF0003, por exemplo, poder impactar no atendimento das necessidades descritas no requisito RF0023. A ordem da leitura da rastreabilidade na matriz poder ser realizada em quaisquer direes escolhidas pelo leitor. Desta forma, define-se que a anlise de impacto das mudanas utilizando mecanismos de rastreabilidade de vital importncia para o gerenciamento de projetos.
4.2.11.
Declarao de Escopo, WBS, Cronograma
O maior esforo despendido para um planejamento do projeto realizada nas execues de atividades relacionadas composio da declarao do escopo, da estrutura analtica do projeto e de cronogramao do projeto. A declarao de escopo documenta os objetivos do projeto e as suas entregas. Baseandose nos requistos do projeto foram especificadas 47 entregas, compostas por um conjunto de servios de treinamento e implantaes, bem como o desenvolvimento de produtos de software, modelos de artefatos e diagramas de processos, dentre outras coisas necessrias. Convm salientar que este trabalho acadmico no contm especificaes detalhadas de cada entrega, o que se faria necessria construo de alguns subprojetos para entregveis que se encaixem em atribuies de complexidade mdia-alta e alta e/ou esforo maior que 10 dias para sua concluso. Algumas restries e premissas tambm foram descritas. A declarao de escopo encontra-se disponvel no Apndice J Declarao do Escopo do Projeto. A estrutura analtica do projeto (WBS) foi criada utilizando-se uma abordagem de diagramao baseada na hierarquia de componentes. No primeiro nvel da WBS encontra-se o ttulo do projeto, chamado Implantao do CMMI-DEV L2. No segundo nvel dispe-se as fases de iniciao, design, piloto e implementao, e que so baseados no mtodo de implantao do CMMI de Kulpa e Johnson (2008).
48
Na fase de iniciao so realizadas entregas de servios que sero evidenciadas de acordo com suas principais caractersticas. Por exemplo, a entrega 1.1. Treinamento envolve a realizao de um curso de introduo ao CMMI para todas as partes envolvidas diretamente com as atividades tcnicas e de gerenciamento direto com o projeto. A evidncia da entrega baseia-se no recebimento de alguma comprovao ou certificado de participao no curso. Com isto, outras entregas importantes so necessrias, como a formao e institucionalizao do Grupo de Processos de Engenharia de Software (SEPG) e a composio de seus membros, a realizao do diagnstico de aderncia do processo atual e a realizao do nivelamento de todos os processos em um processo de desenvolvimento unificado. Na fase de design ou projeto tcnico, sero realizadas vrias adequaes e melhorias ao processo unificado, baseando-se nas metas e prticas de cada uma das 7 reas de processo do CMMI-DEV nvel 2 de maturidade. Ento, para cada rea de processo sero realizados vrios treinamentos e sero desenvolvidos sistemas de software e modelos de artefatos de apoio. A aplicao da melhoria poder ser realizada em pilotos incrementais. Desta forma, podero ser testadas e avaliadas as tcnicas e os procedimentos adotados, verificando-se a sua adequabilidade, o seu custo, a sua velocidade e a sua real necessidade. Na fase piloto sero realizadas a preparao, a execuo, o monitoramento e a anlise dos resultados, bem como a atualizao dos procedimentos a uma realidade mais cabvel. A fase de implementao consiste na realizao de todas as atividades mencionadas anteriormente na fase de piloto para todas as outras unidades organizacionais da empresa, mais a realizao da consolidao do processo que se baseia na melhoria contnua at a plena satisfao das partes interessadas e adequao aos objetivos do CMMI-DEV. O encerramento da fase se dar com a construo e a divulgao das lies aprendidas. Na avaliao sero realizadas a seleo da empresa avaliadora, a realizao de uma avaliao simulada junto a consultoria e a realizao da avaliao oficial. O projeto finaliza com a avaliao dos resultados e lies aprendidas. O cronograma do projeto contm todas as entregas definidas na WBS e o detalhamento das entregas em nvel de atividades. As atividades foram estimadas utilizando-se o mtodo de estimativas de trs pontos (HELDMAN, 2009, p. 162), na opinio especializada e no histrico de estimativas de implantao da melhoria de processos de abordagens semelhantes. O mtodo do caminho crtico (CPM) foi utilizada para determinar as atividades crticas em
49
atividades dependentes. O paralelismo entre vrias atividades foram definidas de acordo com a disponibilidade de recursos e a no dependncia entre elas. Utilizando-se a ferramenta Microsoft Project, foi possvel determinar o esforo total do projeto em cerca de 510 dias teis de 8 horas. Com a alocao dos recursos s atividades, foi possvel determinar o custo inicial do projeto em R$ 312.590,56, o que permite a utilizao de uma reserva de R$ 37.409,44. O projeto inicia-se no dia 01 de fevereiro de 2010 e tem trmino estimado em 08 de fevereiro de 2012. O detalhamento das entregas e das atividades foram realizadas baseando-se em experincias passadas com a implantao das prticas sugeridas pela Melhoria de Processos de Software Brasileira (MPS.BR), que possui abordagem semelhante ao CMMI-DEV4. Todos os artefatos construdos encontram-se no Apndice J Declarao do Escopo do Projeto, Apndice K Estrutura Analtica do Projeto (WBS) e Apndice L Cronograma do Projeto.
4.2.12.
Linha de base de desempenho dos custos
A linha de base de desempenho dos custos o custo total esperado para o projeto ao utilizar um oramento no clculo no trmino (HELDMAN, 2009, p. 206). Possui informaes referente a linha de base de desempenho dos custos e os requisitos de financiamento. Este descreve a necessidade do financiamento ao longo do projeto. Aquele descreve a acumulao dos custos ao longo do tempo do projeto. A linha de base de desempenho dos custos encontra-se no Apndice M Linha de Base de Custos do Projeto.
4.2.13.
Plano de Qualidade e Mtricas de Qualidade
Este documento especifica como sero realizados as atividades de gesto da qualidade e sugere, inicialmente, necessidades de informao para as medies a serem realizadas. A garantia da qualidade do processo envolve a responsabilizao da coordenao e do campeo do projeto na superviso e na auditoria dos procedimentos, bem como em assegurar que o andamento do projeto aderente aos padres de qualidade impostos para o projeto. As
4
Na verdade, o MPS.BR totalmente baseada no CMMI-DEV e nas normas ISO/IEC 15.507 e ISO/IEC 12.204.
50 normas, padres e diretrizes so referenciadas no artefato disponvel no Apndice N Plano de Qualidade e Mtricas do Projeto. As mtricas do projeto so inicialmente sugeridas no documento, necessitando determinar quais so as informaes que devero ser analisadas e medidas durante a execuo do projeto. Pretende-se em futuras adaptaes do projeto realizar esta verificao. Para a realizao das medies sero utilizadas prticas abordadas pela Pratical Software and Systems Measurement (PSM) utilizando o Modelo de Informao para Medio, constante no Apndice O Modelo de Informao para Medio. Uma tima abordagem para medio da melhoria de processos foi definido por Statz (2005) e define quatro dimenses: Custo de Desempenho: custo para desenvolver e providenciar um produto ou servio, baseado nas atividades que so executadas de acordo com o plano. Custo de Preveno: custo para estabelecer e manter processos e treinamentos para execuo do trabalho. Custo de Avaliao: custo para reviso dos produtos e servios sob desenvolvimento, estar certo de que os requisitos sero aceitos e que haja conformidade com o processo. Custo de No Conformidade (Retrabalho): custo incorrido para lidar com defeitos no produto ou servio, incluindo retrabalho no desenvolvimento do produto, reteste, revises etc, bem como o custo de suporte ao cliente, pagamento de penalidades ou multas e outros custos associados aos efeitos dos defeitos. Informaes relevantes sobre necessidades de informao sugeridas foram detalhadas no Apndice N Plano de Qualidade e Mtricas do Projeto.
4.2.14.
Plano de recursos humanos
O plano de recursos humanos documenta as funes e responsabilidades dos indivduos e grupos envolvidos nos diversos elementos do projeto, em nvel de papis, autoridade e competncia. Tambm define o organograma de acordo com os papis e responsabildiades definidos para o projeto. O calendrio de disponibilidade de recursos, as necessidades de treinamentos esto definidas no Apndice P Plano de Recursos Humanos e no cronograma construdo utilizando a ferramenta Microsoft Project.
4.2.15.
Plano de gerenciamento dos riscos
O plano de gerenciamento dos riscos do projeto especifica como os riscos foram definidos, como sero monitorados e controlados ao longo do projeto. Define tambm a
51
estrutura analtica dos riscos (EAR) e as definies adotadas de probabilidade e impacto dos riscos, bem como a matriz de probabilidade e impacto dos riscos. Este plano encontra-se disponvel em Apndice Q Plano de Gerenciamento dos Riscos.
4.2.16.
Planilha de riscos
A planilha de riscos para este projeto constitui-se um dos artefatos mais importantes, pois ele documenta a identificao dos riscos que influenciaro positiva e negativamente o projeto. Cada risco identificado categorizado de acordo com o que foi definido no EAR do projeto, bem como so descritos informaes sobre as possveis causas, probabilidade de ocorrncia numa escala de 0,05 a 0,8 (0,5% a 80%), impacto, grau de risco, conforme definido na matriz de probabilidade e impacto, proprietrio do risco e o plano de resposta aos riscos. Os riscos identificados para o projeto que possuem maior grau so a indisponibilidade de pessoal por causa de suas alocaes a outros projetos ou mesmo o baixo interesse ou descomprometimento dos gerentes das unidades para a realizao das atividades do projeto de melhoria. As aes sugeridas incorrem na realizao de reunies de conscientizao que a melhoria trar para as atividades laborais dos recursos tcnicos e gerenciais, bem como na melhoria do produto. A planilha detalhada de riscos encontra-se disponvel em Apndice R Planilha de Riscos.
52
5. CONSIDERAES FINAIS
De acordo com o planejamento realizado, verificou-se que um planejamento de um projeto de melhoria de processos de desenvolvimento de software baseado nas prticas do CMMI-DEV utilizando as recomendaes do Guia PMBOK interessante sob o aspecto orientado ao controle efetivo dos requisitos e sobre o que dever ser realizado, principalmente quando se adota um processo de implantao sugerido por Kulpa e Johnson (2008). As tcnicas e ferramentas sugeridas pelo Guia facilitam o planejamento assertivo e conclusivo, apesar de demandar um esforo considervel. H uma grande discusso sobre a viabilidade de se manter projetos controlados em detrimento da agilidade, porm, verifica-se que na prtica, nem todos os projetos podero ser planejados utilizando abordagens geis por causa da grande quantidade de riscos inerentes e com alto grau de impacto e probabilidade de acontecimento. O que pode ser realizado so adaptaes e mais adaptaes. Trabalhos futuros visam a adaptao deste planejamento ao melhor controle e gerenciamento dos riscos, bem como o desenvolvimento de sugestes sobre como realizar a melhoria, baseando-se no cenrio proposto por este projeto acadmico.
53
6. REFERNCIAS
1 AHEM, D. M. et al. CMMI SCAMPI distilled appraisals for process improvement. New Jersey, EUA: Addison Wesley Professional, 2005. 2 ALMEIDA, J. A., et al. Viso geral do mtodo de avaliao padro CMMI para melhoria de processos, SCAMPI, v. 1.1. Braslia: Universidade Catlica de Braslia, [19--]. Disponvel em <http://www.sicoobdf.coop.br/c/document_library/ get_file? folderId=46&name=DLFE-30.pdf.>. Acesso em: 10 janeiro 2010. 3 BASTOS, H. C. Experincia SERPRO, estratgia de implantao do CMMI. In: MEETING DE TECNOLOGIA DO UNIP, 2007. Disponvel em <Erro! A referncia de hiperlink no vlida.>. Acesso em: 13 novembro 2007. 4 BUENO, C. F. S.; CAMPELO, G. B. Qualidade de software. Recife: Depart. de Informtica, UFPE, [200-]. Disponvel em <http://www.cin.ufpe.br/~qualisoft/ documentos/diversos/quality.doc>. Acesso em: 27 maro 2010. 5 CHRISSIS, M. B.; KONRAD, M.; SHRUM, S. CMMI guidelines for process integration and product improvement. [S.I.]:Addison Wesley, 2003. 6 HELDMAN, K. Gerncia de Projetos: guia para o exame oficial PMI. 5. ed. Rio de Janeiro: Elsevier, 2009. 7 KULPA, M. K.; JOHNSON, H. A. Interpreting the CMMI: a process improvement approach. 2nd ed. Flrida, EUA: Auerbach Publications, 2008. 8 PESSOA, M. S. P. Introduo ao CMMI, Modelo Integrado de Maturidade e Capacidade de Processos: o novo modelo que substitui o SW-CMM. Lavras: UFLA/FAEPE, 2004. 9 10 PRESSMAN, R. S. Engenharia de software. 6. ed. So Paulo: McGraw-Hill, 2006. PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento de projetos, Guia PMBOK. 4. ed. Pennsylvania, EUA, 2009.
54
11
SOFTWARE ENGINEERING INSTITUTE. Carnegie Mellon University. CMMI para desenvolvimento, verso 1.2. Traduo de Andr Villas Boas e Jos Marcos Gonalves. 2006.
12
STATZ, J. Measurement for process improvement v1.0: technical report. [S.I.: s.n], 2005.
13
VENTURA, P. Exportao de software e o CMMI. Disponvel em <Erro! A referncia de hiperlink no vlida.>. Acesso em: 18 janeiro 2010.
55
GLOSSRIO
Este glossrio utiliza termos consultados do PMBOK (PROJECT MANAGEMENT INSTITUTE, 2009) e do CMMI-DEV for Development (SOFTWARE ENGINEERING INSTITUTE, 2004). Aes corretivas Orientao documentada para que o trabalho do projeto seja executado de modo que seu desempenho futuro esperado fique de acordo com o plano de gerenciamento do projeto. rea de processo Um grupamento de prticas relacionadas de uma rea que, quando implementadas conjuntamente, satisfazem um conjunto de metas consideradas importantes para a realizao de melhorias naquela rea. Atividade Um componente de trabalho realizado durante o andamento de um projeto. Caminho crtico Geralmente, mas no sempre, a sequncia de atividades do cronograma que determina a durao do projeto. o caminho mais longo atravs do projeto. Critrios de aceitao Os critrios que devem ser atendidos antes que as entregas do projeto sejam aceitas. Elicitao de requisitos Uso de tcnicas sistemticas, como prottipos e observaes estruturadas, para identificar e documentar proativamente as necessidades de cliente e usurios finais. Engenharia de Software A aplicao de uma abordagem sistemtica, disciplinada, quantificvel para o desenvolvimento, operao e manuteno de software. Entradas Qualquer item, interno ou externo ao projeto, que exigido por um processo antes que esse processo continue. Pode ser uma sada de um processo predecessor. Entrega Qualquer produto, resultado ou capacidade para realizar um servio nico e verificvel e que deve ser produzido para concluir um processo, uma fase ou um projeto. Muitas vezes utilizado mais especificamente com referncia a uma entrega externa, que uma entrega sujeita aprovao do patrocinador ou do cliente do projeto. Escopo a soma dos produtos, servios e resultados a serem fornecidos na forma de projeto.
56 Esforo Quantidade de unidades de mo de obra necessrias para terminar uma atividade do cronograma ou componente da estrutura analtica do projeto. Estimativa de trs pontos Uma tcnica que usa trs estimativas de custos ou durao para representar os cenrios otimista, mais provvel e pessimista. Esta tcnica aplicada para melhorar a exatido das estimativas de custos ou durao quando no h certeza em relao atividade subjacente ou ao componente de custo. Linha de base Um plano aprovado para um projeto, somadas ou subtradas de mudanas aprovadas. Matriz de rastreabilidade de requisitos Uma tabela que liga os requisitos s suas origens e os rastreia durante todo o ciclo de vida do projeto. Mtodo da cadeia crtica Uma tcnica de anlise de rede do cronograma que modifica o cronograma do projeto para que se leve em conta a limitao de recursos. Mtodo do caminho crtico (CPM) Uma tcnica de anlise de rede do cronograma elaborada para determinar a flexibilidade na elaborao de cronogramas (a quantidade de folga) nos diversos caminhos lgicos da rede do cronograma de projeto e para determinar a durao mnima total do projeto. As datas de incio e de trmino mais cedo so calculadas atravs de um caminho de ida, usando uma data de trmino especificada. As datas de incio e de trmino mais tarde so calculadas atravs de um caminho de volta, comeando de uma data de trmino especificada, que ocasionalmente a data de trmino mais cedo do projeto determinada durante o clculo do caminho de ida. Oramento A estimativa aprovada para o projeto ou qualquer componente da estrutura analtica do projeto ou atividade do cronograma. Prtica Um tipo especfico de atividade profissional ou de gerenciamento que contribui para a execuo de um processo e que pode empregar uma ou mais tcnicas e ferramentas. Premissas So fatores que, para fins de planejamento, so considerados verdadeiros, reais ou certos sem prova ou demonstrao. Requisito Uma condio ou capacidade que deve ser atendida ou possuda por um sistema, produto, servio, resultado ou componente para satisfazer um contrato, uma norma, uma especificao ou outro documento impostos formalmente. Os requisitos incluem necessidades, desejos e expectativas quantificados e documentados do patrocinador, do
cliente e de outras partes interessadas.
57 Retrabalho Ao tomada para fazer com que um componente imperfeito ou fora das especificaes fique em conformidade com os requisitos ou especificaes. Sadas Um produto, resultado ou servio gerado por um processo. Pode ser necessrio para um processo sucessor. Solicitao de mudana Solicitaes para aumentar ou reduzir o escopo do projeto, modificar polticas, processos, planos ou procedimentos, modificar custos ou oramentos ou revisar cronogramas.
58
APNDICE A TERMO DE ABERTURA DO PROJETO
59
Termo de Abertura do Projeto

Projeto de Implantao do CMMI-DEV L2
19/01/2010 eGovernment Solues e Servios Luiz Alves, Assessor Tcnico da Presidncia
60
Termo de Abertura do Projeto

1. Propsito e justificativa do projeto

Este projeto tem por propsito estabelecer diretrizes para a realizao da implantao da melhoria de processos de desenvolvimento de software, baseado nas prticas definidas de acordo com o Capability Maturity Model Integration for Development nvel 2 de maturidade (CMMI-DEV L2). Este projeto justificado pela necessidade de negcio e planejamento estratgico descritos na Declarao de Trabalho do Projeto.
2. Objetivos do projeto
O objetivo do projeto realizar a criao e a adequao de um processo de desenvolvimento de software da empresa ao alcance das metas e a realizao das prticas recomendadas pelo modelo CMMI-DEV L2, aonde for aplicvel, possibilitando a construo de um processo executvel e manutenvel. O escopo de execuo do projeto de melhoria do processo ser aplicado com foco nas unidades Oramentria e Administrativa, Tributria, Recursos Humanos e as unidades de apoio JAVA e .NET. O principal critrio de sucesso para este projeto a realizao de uma avaliao positiva, aonde venha indicar que organizao est madura para o nvel pretendido e obter o selo de qualidade, dentro do oramento previsto de R$ 350.000,00 em um prazo mximo de concluso de dois anos e meio. Ser institucionalizada a formao do Grupo de Processos de Engenharia de Software (SEPG) da empresa.
3. Requisitos gerais do projeto

Uma lista geral dos requisitos dos interessados relacionada abaixo: 1. Atingir as metas determinadas no planejamento estratgico da organizao para o binio; 2. Conquistar um selo de qualidade de nvel internacional para os servios de TI; 3. No ultrapassar o oramento previsto de R$ 350.000,00; 4. Obter retorno do investimento em trs anos; 5. No ultrapassar o prazo de dois anos e meio para entrega do processo de desenvolvimento implementado e institucionalizado, o que no inclui a avaliao;
61
6. Capacitar tecnicamente as equipes de desenvolvimento com o objetivo de resolver os problemas decorrentes de servios no projetados adequadamente;
4. Descrio do projeto
O projeto baseado na execuo das atividades para alcance dos objetivos da organizao e das metas do modelo, que so baseados no CMMI-DEV L2, composto de 7 reas de processo: Gesto de Requisitos (REQM), Planejamento de Projeto (PP), Monitoramento e Controle de Projeto (PMC), Gesto de Contrato com Fornecedor (SAM), Medio e Anlise (MA), Garantia da Qualidade de Processo e de Produto (PPQA), e Gesto de Configurao (GC). Os envolvidos que participaro da avaliao do projeto compem os gerentes de unidades, analistas-desenvolvedores e quaisquer outros recursos que possam ser contratados.
5.
Riscos do projeto
Os principais riscos identificados para este projeto so: Resistncia mudana da cultura organizacional; Incredulidade de alguns envolvidos acerca dos efeitos positivos da aderncia dos processos com base no modelo; Inexperincia da maioria dos envolvidos poder dificultar a implantao; Baixa disponibilidade da maioria dos envolvidos para o projeto; Resistncia inicial da alta gerncia ao apoio total na mitigao de alguns riscos do projeto.
6. Cronograma de marcos
62
7. Resumo do oramento
Custos aproximados para a realizao do projeto: R$ 320.000,00 O gerente designado para coordenar o projeto ser Ana Beatriz. de sua responsabilidade a garantia de execuo do projeto dentro dos objetivos impostos por este documento. institucionalizado o Grupo de Processos de Engenharia de Software, tendo a mesma como coordenadora do grupo.
X
Joo da Silva Presidente
63
APNDICE B DECLARAO DE TRABALHO DO PROJETO
64
Declarao do Trabalho do Projeto

A eGovernment Solues e Servios formaliza atravs deste documento a necessidade de realizar o projeto: Implantao do CMMI-DEV nvel 2. Devero ser produzidos para este projeto os servios e resultados esperados de acordo com o que definido nas sees que discorrem sobre a necessidade do negcio, escopo do projeto e plano estratgico da empresa.
1. Necessidade do negcio
Com o objetivo de melhorar a qualidade de seus produtos e servios, a empresa verificou a real necessidade de realizar modificaes nos procedimentos de trabalho de sua equipe tcnica de desenvolvimento. A necessidade do negcio relacionada a:
1.
Demanda do mercado, que vem exigindo urgentemente um aprimoramento na qualidade dos produtos de software entregues pela empresa. Isto somente poder ser alcanado pela melhoria do processo de desenvolvimento de software, baseando-se nas melhores prticas e padres de qualidade da Engenharia de Software. Inclusive, algumas entidades governamentais, como potenciais clientes, esto exigindo a certificao como pr-requisito para participao em certames licitatrios; Oportunidade estratgica, onde a aquisio de uma certificao de nvel internacional poder garantir melhor presena da organizao perante os mercados interno e externo, revelando o compromisso da empresa com a qualidade de seus servios e produtos, adquirindo maior respeitabilidade;
2.
3. Necessidade interna, em organizar e padronizar os procedimentos para desenvolvimento de software da empresa, que atualmente encontra-se em estado muito precrio. tambm necessrio obter melhor satisfao dos nossos colaboradores e assim evitar a alta rotatividade de pessoal. 4. Necessidade social, adicionando atendimento de qualidade dos nossos clientes sociedade.
2. Escopo do projeto
Fazem parte do escopo deste projeto: 1. Realizao do levantamento dos problemas atuais relacionados aos procedimentos de trabalho das equipes tcnicas das unidades organizacionais da empresa; 2. Contratao de consultoria especializada e aquisio de ferramentas; 3. Capacitao das equipes para a execuo das prticas recomendadas pelo CMMI-DEV, nvel 2. 4. Criao de um processo padro de desenvolvimento de software; 5. Contratao da equipe CMMI de avaliao; 6. Obteno do certificado CMMI-DEV nvel 2 para a empresa.
65
3. Planejamento estratgico
De acordo com o planejamento estratgico da empresa definido para o binio 2010/2011, atravs de uma reviso das informaes histricas e um cenrio previsto, foram definidas as seguintes metas: Reestruturar os procedimentos de servios bases; Conquistar um selo de qualidade de nvel internacional para servios de TI; Divulgar nossas conquistas e vender aos clientes produtos de qualidade; Vender e implantar trs dos nossos principais produtos para clientes estratgicos: prefeituras de cidades com populao superior a 500.000 habitantes e entidades de governos estaduais; Atingir 3 milhes de reais em servios e vendas do Sistema de Arrecadao Municipal e do Sistema de Controle Oramentrio; Realizar planejamento para exportao dos produtos e servios para pases do MERCOSUL. Este projeto far parte das aes previstas no planejamento estratgico e ser patrocinado pela presidncia.
X
66
APNDICE C REGISTRO DAS PARTES INTERESSADAS
67
Registro das partes interessadas

Projeto: Implantao do CMMI-DEV L2 Gerente do Projeto: Ana Beatriz Nvel de conhecime Expectativas nto Obter avaliao Nenhum positiva sobre a implantao Baixo Nenhum Diminuir gastos com recursos humanos e materiais. Obter lucro. Obter avaliao positiva sobre a implantao e capacitar as equipes tcnicas Adequar os processos e as pessoas s metas do CMMI-DEV L2 Obter avaliao positiva sobre a implantao. Evitar retrabalho. Capacitar sua equipe. Capacitar-se tecnicamente. Obter experincias positivas.
Setor
Nome
Papel na empresa
Cargo funcional
Papel no projeto
Relaciona mento
Nveis de influncia Bastante significativa Significativa Muito significativa Bastante significativa Muito significativa
Impacto
Telefone
Email
Presidncia Assessoria Gesto Financeira
Joo da Silva Luiz Alves Maria Silva
Presidente Assessor tcnico da presidncia Diretora financeira
Administrador Snior Engenheiro de Software Snior Contabilista Snior
Patrocinado Interno r Campeo Interno Interno
Alto MdioAlto Alto
(83) 3222-1234 joao.silva@egovss.com.br (83) 3222-1235 luiz.alves@egovss.com.br (83) 3222-1236 maria.silva@egovss.com.br
SEPG
Ana Beatriz
Gerente de unidade
Engenheiro de Software Snior
Coordenado Interno ra Consultor CMMI
Mdio
Alto
(83) 3222-1237 ana.beatriz@egovss.com.br
Evandro Tavares
Externo
Alto
Alto
(83) 4333-2534 evandro@consultoria.com.br
Daniela Amorim
Gerente de unidade
Gerente Pleno
Membro do Interno worktime
Mdio
Significativa
MdioAlto
(83) 3222-1238 daniela.amorim@egovss.com.br
Saulo de Tarso
Unidade de Desenvolvime nto Recursos Humanos
Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor Gerente de unidade
Engenheiro de Software Pleno Engenheiro de Software Jnior Engenheiro de Software Jnior Engenheiro de Software Jnior Engenheiro de Software Jnior Gerente Pleno
Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime
Mdio Baixo Baixo Baixo Baixo Mdio
Significativa Pouca
Mdio Mdio Mdio Mdio Mdio MdioAlto
(83) 3222-1239 saulo.tarso@egovss.com.br (83) 3222-1239 tarcisio.meira@egovss.com.br (83) 3222-1239

ubirajara.queiroga@egovss.com.b r
Tarcsio Meira Ubirajara Queiroga Vanessa Amaral Wesley Patrcio
Capacitar-se tecnicamente.
Pouca Pouca Pouca
(83) 3222-1240 vanessa.amaral@egovss.com.br (83) 3222-1240 wesley.patricio@egovss.com.br (83) 3222-1241 carlos.eduardo@egovss.com.br
Unidade de Carlos Eduardo Desenvolvime nto Oramentria e Luciano Pereira Administrativa
Analista-desenvolvedor
Engenheiro de Software Pleno
Mdio
Obter avaliao positiva sobre a implantao Capacitar-se tecnicamente. Obter experincias positivas. Diminuir reatrabalho.
Significativa
Significativa
Mdio
(83) 3222-1242 luciano.pereira@egovss.com.br
68
Capacitar-se tecnicamente. Obter melhores prazos para as entregas. Capacitar-se tecnicamente.
Marta Andrade
Analista-desenvolvedor
Engenheiro de Software Pleno Engenheiro de Software Jnior Engenheiro de Software Jnior Engenheiro de Software Jnior Engenheiro de Software Pleno Engenheiro de Software Jnior
Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime
Mdio
Pouca
Mdio
(83) 3222-1242 marta.andrade@egovss.com.br
Nair Belo Olavo Mesquita Patrcia Pilar Quirino Peixoto Renata de S
Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor
Baixo Baixo Baixo Mdio Baixo
Pouca Pouca Pouca
Mdio Mdio Mdio Mdio Mdio
(83) 3222-1242 nair.belo@egovss.com.br (83) 3222-1242 olavo.mesquita@egovss.com.br (83) 3222-1242 patricia.pilar@egovss.com.br (83) 3222-1243 querino.peixoto@egovss.com.br (83) 3222-1243 renata.sa@egovss.com.br
Pouca Pouca
Bernardo Antnio
Gerente de unidade
Gerente Pleno
Membro do Interno worktime
Baixo
Obter avaliao positiva sobre a implantao e melhorar os procedimentos de trabalho Diminuir retrabalho.
Significativa
MdioAlto
(83) 3222-1244 bernardo.antonio@egovss.com.br
Fabiana Azevedo Analista-desenvolvedor

Unidade de Desenvolvime nto Tributria
Engenheiro de Software Jnior Engenheiro de Software Jnior Engenheiro de Software Jnior Engenheiro de Software Pleno Engenheiro de Software Jnior Analista de Suporte Snior Analista de Suporte Pleno Analista de Suporte Jnior
Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Membro do Interno worktime Suporte Suporte Suporte Interno Interno Interno
Baixo Baixo Baixo Mdio Baixo Baixo Nenhum Nenhum
Pouca Pouca Pouca
Mdio Mdio Mdio Mdio Mdio Mdio Mdio Mdio
(83) 3222-1245 fabiana.azevedo@egovss.com.br (83) 3222-1245

george.vasconcelos@egovss.com. br
George Vasconcelos Hugo Almeida Iara Joaquina Joana Pereira Waldemar Nogueira
Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor Analista-desenvolvedor Gerente de tecnologia Analista de suporte Analista de suporte
(83) 3222-1245 hugo.almeida@egovss.com.br (83) 3222-1246 iara.joaquina@egovss.com.br (83) 3222-1246 joana.pereira@egovss.com.br (83) 3222-1247
waldemar.nogueira@egovss.com. br
Pouca Pouca Pouca Pouca Pouca
Tecnologia e Suporte
Ricardo Carneiro Vicente Silva
(83) 3222-1248 ricardo.carneiro@egovss.com.br (83) 3222-1248 vicente.silva@egovss.com.br
69
APNDICE D PLANO DE GERENCIAMENTO DO PROJETO
70
Plano de Gerenciamento do Projeto

19/01/2010 eGovernment Solues e Servios Ana Beatriz, Coordenadora do Projeto
71
Contedo
1. 1.1. 1.2. 2. 2.1. 2.2. 2.3. 3. 3.1. 3.2. 3.3. 4. 5. 5.1. 6. 7. 8. Introduo ............................................................................................................ 72 Definies, Acrnimos e Abreviaes .................................................................. 72 Referncias ........................................................................................................... 72 Viso Geral do Projeto ......................................................................................... 73 Finalidade, Escopo e Objetivos do Projeto .......................................................... 73 Suposies e Restries ....................................................................................... 73 Entregas ............................................................................................................... 73 Planejamento e Controle do Projeto ................................................................... 74 Partes Interessadas .............................................................................................. 74 Recursos ............................................................................................................... 74 Estimativas do Projeto ......................................................................................... 75 Cronogramao do Projeto .................................................................................. 76 Monitoramento e Controle do Projeto ................................................................ 76 Monitoramento do Projeto .................................................................................. 76 Gerenciamento de Comunicao ......................................................................... 77 Encerramento do Projeto..................................................................................... 77 Aprovaes........................................................................................................... 77
72
Plano de Gerenciamento do Projeto

1.
Introduo
A finalidade deste Plano de Gerenciamento de Projetos reunir todas as informaes necessrias ao projeto. Este plano segue as atividades que constam no cronograma e baseado nas atividades necessrias ao alcance dos objetivos descritos no Termo de Abertura do Projeto.
1.1. Definies, Acrnimos e Abreviaes

Consulte o Glossrio do Projeto.
1.2. Referncias
Termo de Abertura do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01.Termo de Abertura de Projeto.docx Cronograma do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/03b.Cronograma do Projeto.mpp Registro das partes interessadas, disponvel em http://www.egovss.com.br/intra/sepg/P001/02a. Registro das partes interessadas.xlsx Documento de Requisitos, disponvel em http://www.egovss.com.br/intra/sepg/P001/ 04a.Requisitos do Projeto.docx Linha de Base de Desempenho dos Custos, disponvel em http://www.egovss.com.br/intra/sepg/P001/ 07a.Linha de base do desempenho dos custos.xlsx Declarao do Escopo do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/05a.Declarao do Escopo do Projeto.docx
73
2. Viso Geral do Projeto

Esta seo apresenta uma viso geral do projeto e descreve a sua finalidade, escopo, objetivo, as suposies e restries preliminares do projeto, os produtos e servios a serem entregues.
2.1. Finalidade, Escopo e Objetivos do Projeto

O escopo do projeto est definido na Declarao do Escopo do Projeto e no Cronograma do Projeto. Classificao do Projeto
Novo Produto Novo Servio Manuteno do Produto Evolutiva Adaptativa Corretiva Preventiva Tabela 8 - Classificao geral do projeto
2.2. Suposies e Restries

As suposies e restries para o projeto esto descritos no Documento de Requisitos.
2.3. Entregas
Produtos Processo de Desenvolvimento de Software; Modelos de artefatos necessrios execuo das atividades do processo; Definio de papis, contendo atribuies, responsabilidades e requisitos para contrao; Sistemas de banco de dados de requisitos e de rastreabilidade; Sistemas de comunicao;
Servios Implantao de sistemas servidores de banco de dados, distribuio de informaes (sites) e de projetos; Implantao de sistema de controle de verso; Realizao de treinamentos em gerenciamento de projetos, de configurao, aquisies, medio e anlise, qualidade de processo e de produto.
74
3. Planejamento e Controle do Projeto

Esta seo descreve como ser definido o planejamento e o controle do projeto.
3.1. Partes Interessadas

As partes interessadas deste projeto esto descritas no Registro das Partes Interessadas.
3.2. Recursos
Esta seo descreve os recursos necessrios para o projeto. 3.2.1. Estrutura Organizacional do Projeto A estrutura organizacional do projeto representada abaixo baseada na hierarquia de papis. O Cronograma do Projeto, visualizao da Planilha de Recursos, relaciona quem so as pessoas que assumiro estes papis.
Coordenao
Consultoria
Worktimes
Gerentes de Unidade
Analistas
Figura 7 - Estrutura Organizacional
3.2.2. Recursos Humanos, de Materiais e de Custo Os recursos humanos, de materiais e de custos extras esto definidos no Cronograma do Projeto, visualizao da Planilha de Recursos, bem como demais informaes contidas em relatrios de disponibilidade, de esforo sobre o tempo, esforo acumulado, horas extras etc.
75
3.3. Estimativas do Projeto

Esta seo descreve as estimativas do projeto. 3.3.1. Esforo As estimativas de esforo so encontradas no Cronograma deste projeto. O mtodo utilizado para determinao do esforo baseado na tcnica PERT de estimativas, utilizando estimativas de casos normais, pior caso e melhor caso para cada atividade estabelecida no cronograma. O esforo da atividade baseia-se na mdia aritmtica conforme definido na equao abaixo:
=
3.3.2. Custos
+ 4 + 6
As estimativas de custos do projeto esto definidas na Planilha de Custos relativa a este plano que se encontra no Cronograma do Projeto. A estimativa de custos baseada no esforo planejado para execuo de cada atividade utilizando determinados recursos alocados. Os recursos humanos tem seu custo baseado no valor/hora de suas atividades e os recursos materiais e de custos extras tiveram seus custos estimados baseado em informaes histricas de projetos semelhantes. 3.3.3. Oramento A linha de base do desempenho dos custos e os requisitos de financiamento esto definidos no arquivo correspondente ao projeto e so representados abaixo. Seus dados so oriundos das estimativas de custos de cada atividade do projeto.
R$ 350.000,00 R$ 300.000,00 R$ 250.000,00 R$ 200.000,00 R$ 150.000,00 R$ 100.000,00 R$ 50.000,00 R$ 0,00
Fevereiro Maro Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro Maro Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro
2010
Custo Custo Acumulado
2011
Requisitos de Financiamento
2012
76
Os requisitos de financiamento tm incremento trimestral e comporo a base oramentria a ser despendida em cada perodo.
4. Cronogramao do Projeto
O cronograma do projeto poder ser encontrado no repositrio do projeto.
5. Monitoramento e Controle do Projeto

Esta seo descreve como ser realizado o monitoramento e o controle do projeto.
5.1. Monitoramento do Projeto

Na fase de planejamento, o gerente snior dever aprovar o projeto. O plano de projeto e o cronograma devero ser apresentados e a partir da aprovao, o projeto estar validado para a execuo. Na execuo do projeto, o monitoramento deve ser realizado de acordo com a tabela a seguir:
Tipo
Monitoramento Dirio Monitoramento Planejado Revises em Marcos Acompanhamento Gerencial
Periodicidade
Realizado por
Gerente do Projeto Gerente do Projeto Gerente do Projeto Comit Gerencial
Produtos gerados
Ferramenta/tcnica utilizada
Project Server Verificao da atualizao diria das atividades Avaliao semanal do projeto Avaliao dos marcos do projeto Reunio de Acompanhamento
Diariamente
Semanalmente Em marcos planejados no cronograma Quinzenalmente
Planilha de Acompanhamento Planilha de Acompanhamento Ata de Acompanhamento
Tabela 9 - Acompanhamento do Projeto
Em cada tipo de monitoramento, o foco diferenciado buscando identificar eventos que podem alterar o planejamento. Essa alterao pode no influenciar negativamente o projeto, mas deve ser acompanhado e aprovado pelos envolvidos. As mudanas e problemas que surgem no decorrer do projeto e que impactam negativamente devem ser identificados e, quando possvel, aes sero tomadas para contingenciar esses impactos e mape-los, para que em outros projetos o mesmo no ocorra, ou pelo menos, seja minimizado. O controle de mudanas do projeto considerar solicitaes referentes s mudanas entre o que foi planejado e o realizado, bem como controlar as alteraes de escopo do projeto referentes s solicitaes de mudana. Tais solicitaes podem ser propostas pelo cliente ou pela equipe de desenvolvimento do projeto, sendo passveis de um novo dimensionamento do esforo e custo necessrios para sua implementao.
77
Para que uma alterao seja incorporada ao projeto, o impacto dessa alterao deve ser avaliado (custo, esforo, prazo...) e dever ser aprovada pelo cliente.
6. Gerenciamento de Comunicao
A execuo da comunicao ser baseada nas evidncias geradas pelos artefatos descritos na tabela abaixo e sua gerncia acontecer de acordo com o previsto no cronograma. Tipo de Comunicao
Abertura do Projeto Controle de Mudana Acompanhamento
Formato da Comunicao
Reunio de Kickoff com toda a equipe do projeto Reunio, email Email, reunio, apontamentos no Project Web Access Tabela 10 - Gerenciamento de Comunicao
Pblico Alvo
Equipe do projeto Equipe do projeto e demais interessados Equipe do projeto
As partes interessadas do projeto esto relacionadas no Registro das partes interessadas.
7. Encerramento do Projeto
O encerramento deste projeto estar baseada nas evidncias geradas baseando-se na Declarao de Escopo deste projeto e no trmino da ltima atividade descrita no Cronograma do Projeto. O projeto ser efetivado com sucesso se todos os objetivos definidos no Termo de Abertura e Declarao de Trabalho foram alcanados e se todos os requisitos do projeto foram atendidos. Deve-se observar que a obteno do selo de qualidade que comprova se a organizao observa e executa as prticas definidas no CMMI-DEV nvel 2, no a nica evidncia de sucesso deste projeto pois deve tambm ser observado se as prticas trouxeram os benefcios esperados e que a satisfao da maioria seja alcanada.
8. Aprovaes
Tendo cincia da execuo do projeto, dos prazos, dos custos e do oramento previstos de acordo com o que foi estabelecido neste Plano de Projeto, firmamos o compromisso o mesmo:
X
X
Ana Beatriz Coordenadora do Projeto
79
APNDICE E PLANILHA DE ACOMPANHAMENTO DO PROJETO
81
Planilha de Acompanhamento do Projeto

Implantao do CMMI-DEV L2 Tipo: Data: Responsvel:
Objetivo(s) do Marco: Avaliao do Marco:
Parmetro
Situao
Motivo da Alterao
Avaliao
Observao
Escopo
Mantido
Custo Interno
Mantido
Prazo
Mantido
Esforo
Mantido
Cronograma
Mantido
Riscos
Mantido
Acompanhamento da Gerncia de Mudana de Escopo

Selecione/marque as caixas para as perguntas cuja resposta seja afirmativa. Para as perguntas com resposta negativa no selecione as caixas e realize uma anlise para esse ponto.
Anlise
82
Acompanhamento das Aes Anteriores
N Acompanhamento # problema
Ao
Situao
Resultado
Responsvel
Lista de Problemas
Problema
# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Problema Anlise Ao
Plano de Ao
Responsvel Data da ao
83
APNDICE F REQUISITOS DO PROJETO
84
Requisitos do Projeto
85
Contedo
1. Introduo.............................................................................................................................................. 86
1.1. 1.2. Definies, acrnimos e abreviaes ................................................................................................. 86 Referncias ......................................................................................................................................... 87
2.
Viso geral do projeto ............................................................................................................................ 87

2.1. 2.2. Necessidade e objetivos de negcio e de projeto.............................................................................. 87 Escopo de execuo do projeto ......................................................................................................... 87
3.
Requisitos funcionais ............................................................................................................................. 88

3.1. 2.1. Preparao ......................................................................................................................................... 88 Aderncia ao modelo CMMI-DEV nvel de maturidade 2 .................................................................. 89
2.1.1. rea de Processo: Gerenciar Requisitos (REQM) ............................................................................... 89 2.1.2. rea de Processo: Planejamento de Projeto (PP) .............................................................................. 91 2.1.3. Implantao da rea de Processo: Monitoramento e Controle do Projeto (PMC) ........................... 93 2.1.4. Implantao da rea de Processo: Gesto de Acordo com os Fornecedores (SAM) ......................... 94 2.1.5. Implantao da rea de Processo: Medio e Anlise (MA).............................................................. 96 2.1.6. Implantao da rea de Processo: Garantia da Qualidade de Processo e Produto (PPQA) .............. 97 2.1.7. Implantao da rea de Processo: Gesto da Configurao (CM) ..................................................... 98 2.1.8. Implantao das reas de Processos de acordo com as Metas Genricas (GG) definidas ................ 99
4.
Requisitos no funcionais .................................................................................................................... 100

4.1. 4.2. 4.3. 4.4. 4.5. 4.6. Infraestrutura ................................................................................................................................... 100 Acessibilidade ................................................................................................................................... 101 Segurana ......................................................................................................................................... 101 Disponibilidade ................................................................................................................................. 101 Recursos de custo ............................................................................................................................. 101 Padres ............................................................................................................................................. 101
5. 6.
No-requisitos ...................................................................................................................................... 102 Critrios de aceitao .......................................................................................................................... 102
86
Requisitos do Projeto
1. Introduo
A finalidade deste documento de requisitos do projeto descrever os requisitos do produto ou servio e as caractersticas das entregas, fornecendo informaes necessrias para satisfao dos objetivos do projeto.
1.1.
Definies, acrnimos e abreviaes
Esta subseo fornece as definies de todos os termos, acrnimos e abreviaes necessrias adequada interpretao do documento de requisitos do projeto. Algumas abreviaes e termos prprios do documento de requisitos so descritos abaixo: Identificao dos requisitos: por conveno, a referncia aos requisitos feita atravs do identificador de requisitos, de acordo como descrito abaixo: [IDENTIFICADOR DO TIPO DO REQUISITOidentificador do requisito] O identificador do tipo de requisito conforme abaixo: o o o RF Requisito Funcional RNF Requisito No Funcional NR No-Requisito
O identificador do requisito ser uma sequencia numrica. Esse nmero sequencial ser nico para todo o conjunto de tipos de requisitos. Exemplo: RF0001, RF1234, RNF1234, NR1212 Atributos dos Requisitos: os atributos de requisitos estabelecidos so: o o o o Prioridade: Essencial, Importante, Desejvel Complexidade: Complexa, Alta, Mdia ou Baixa. Risco: Alto, Mdio, Baixo reas organizacionais e entidades externas afetadas
Para as definies ou termos, acrnimos e abreviaes do projeto, consulte o Glossrio do Projeto.
87
1.2.
Referncias
Declarao do Trabalho do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01a.Declarao do Trabalho do Projeto.docx Termo de Abertura do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01.Termo de Abertura de Projeto.docx Registro das partes interessadas, disponvel em http://www.egovss.com.br/intra/sepg/P001/02a. Registro das partes interessadas.xlsx Cronograma do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/03b.Cronograma do Projeto.mpp Capability Maturity Model Integration for Development (CMMI-DEV) v 1.2.
2. Viso geral do projeto

Esta seo apresenta uma viso geral do projeto e descreve a sua finalidade, escopo, objetivo, as suposies e restries preliminares do projeto, os produtos e servios a serem entregues.
2.1. Necessidade e objetivos de negcio e de projeto

As necessidades e os objetivos de negcio esto descritos na Declarao do Trabalho do Projeto. Os propsitos, as justificativas e os objetivos do projeto esto descritos no Termo de Abertura do Projeto.
2.2. Escopo de execuo do projeto

O escopo de execuo do projeto de melhoria est descrito no Termo de Abertura de Projeto. Deste modo, quando o requisito se referir rea organizacional ou entidade externa afetada como Todas, ento a implementao do requisito ser realizada em todas as unidades e entidades constantes naquele documento. Algumas outras reas ou entidades sero identificadas de acordo com o levantamento dos requisitos deste projeto.
88
3. Requisitos funcionais
Esta seo descreve os requisitos funcionais do projeto, e so expressos no estilo de linguagem natural.
3.1. Preparao
Esta categoria de requisitos representa todos os requisitos necessrios preparao para a execuo da melhoria do processo. RF0001 Avaliao preliminar SCAMPI Dever ser realizada a avaliao preliminar da aderncia dos procedimentos atuais de acordo com as metas e prticas do CMMI-DEV nvel 2 de maturidade de acordo com os procedimentos do mtodo de avaliao SCAMPI. Atributos
Complexidade: Complexa Alta Risco: Prioridade: Alto Mdio Mdia Baixo Baixa
Essencial Importante Desejvel
reas organizacionais e entidades externas afetadas:

1. Todas
RF0002 Coleta e anlise dos Indicadores de Implementao das Prticas (PII) Dever ser realizada a coleta e a anlise dos Indicadores de Implementao das Prticas (PII) com o objetivo de manter informaes de como as prticas so realizadas na organizao. Atributos

1. Todas
RF0003 Formao e institucionalizao do Grupo de Processos de Engenharia de Software (SEPG) Dever ser realizada a formao e a institucionalizao do Grupo de Processo de Engenharia de Software (SEPG) cuja responsabilidade ser de estabelecer a
89
estrutura da melhoria de processos, direcionando e monitorando suas atividades. Ser composta por duas pessoas, um coordenador e um responsvel tcnico. As pessoas qualificadas devero ter algumas das caractersticas discriminadas abaixo: 1. Autoiniciativa e criatividade; 2. Experincia, podendo incluir pessoas que tm executado diferentes trabalhos na organizao ou em outras empresas; 3. Conhecimento em Engenharia de Software; 4. Conhecimento em Engenharia de Processos; 5. Possuir bom histrico tico e profissional; 6. Saber escrever bem. Atributos

1. Todas
3.2. Aderncia ao modelo CMMI-DEV nvel de maturidade 2

Esta categoria de requisitos representa todos os requisitos necessrios adequao do processo de desenvolvimento de software de acordo com as metas e prticas do CMMIDEV nvel de maturidade 2. 3.2.1. rea de Processo: Gerenciar Requisitos (REQM) RF0004 Realizao do gerenciamento dos requisitos e identificao das inconsistncias dos produtos de trabalho com os planos de projetos de acordo com a Meta Especfica SG1: Gerenciar Requisitos e Prticas Especficas SP 1.1 e 1.2. Dever ser especificada no processo a realizao do gerenciamento dos requisitos e a identificao das inconsistncias dos produtos de trabalho com os planos de projetos. Desta forma dever ser realizado: 1. Especificao da lista de critrios para escolha e distino de fornecedores de requisitos do projeto; 2. Definio de critrios para avaliao e aceitao de requisitos no processo; 3. Definio de um modelo de documento de aceitao e comprometimento com os requisitos, que permita comprovar a aceitao e o comprometimento com os requisitos pelos dos clientes e pela organizao;
90
Atributos

1. 2. Todas SEPG
RF0005 Gerenciamento das mudanas dos requisitos medida que evoluem durante o projeto de acordo com a Meta Especfica SG1: Gerenciar Requisitos e Prtica Especfica SP 1.3. Dever ser realizado gerenciamento das mudanas dos requisitos conforme as mudanas ocorram em um projeto. Desta forma dever ser construdo um sistema de banco de dados de requisitos que possibilite o armazenamento, o histrico de mudanas e informaes sobre a anlise de impacto das mudanas dos requisitos. As informaes relativas anlise de impacto consistem nas descries de custos, oramento, complexidade, tamanho e viabilidade tcnica para a implementao do requisito. Estes dados devero estar disponveis ao projeto. Atributos
Complexidade: Complexa Alta Risco: Prioridade: Alto Essencial Mdio Mdia Baixo Baixa
Importante Desejvel

1. 2. Todas SEPG
RF0006 Manter a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho de acordo com a Meta Especfica SG1: Gerenciar Requisitos e Prtica Especfica SP 1.4. Atravs do sistema de banco de dados de requisitos, dever ser possvel manter a rastreabilidade vertical e horizontal bidirecionais para os requisitos. Para os outros produtos de trabalho, dever ser possvel manter a rastreabilidade para cada nvel de decomposio do produto utilizando outros mecanismos. Desta forma, ser possvel manter o vnculo de um requisito com outros requisitos derivados e com a sua alocao a funes, interfaces, pessoas, processos e produtos de trabalho. A disponibilizao das informaes de rastreabilidade ser mantida em forma de uma matriz.
91
Atributos

1. 2. Todas SEPG
RF0007 Identificar inconsistncias entre trabalho de projeto e requisitos de acordo com a Meta Especfica SG1: Gerenciar Requisitos e Prtica Especfica SP 1.5. Devero ser documentadas todas as inconsistncias entre os planos de projeto, produtos de trabalho e os requisitos resultantes das mudanas da baseline do projeto, incluindo as origens, condies e fundamento lgico. Aps a identificao das inconsistncias, devero ser realizados o planejamento e a execuo das aes corretivas. Atributos

1. 2. Todas SEPG
3.2.2. rea de Processo: Planejamento de Projeto (PP) RF0008 Estabelecimento das estimativas de acordo com a Meta Especfica SG1: Estabelecer Estimativas e Prticas Especficas SP 1.1, 1.2, 1.3 e 1.4. Devero ser mantidas e estabelecidas as estimativas dos parmetros do plano de projeto. Para isto dever ser implantando um mecanismo que implemente a estrutura de decomposio de trabalho (WBS) suficientemente detalhado em nveis de pacotes de trabalho de modo que possa permitir realizar estimativas para os projetos, tarefas, responsabilidades e cronograma, baseados na arquitetura do produto e nos atributos de produtos de trabalho. O mecanismo tambm dever permitir a definio de um ciclo de vida para um projeto, com o objetivo de determinar o escopo do esforo do planejamento, as estimativas de custo, esforo e tarefas. O mecanismo dever estar em um servidor de dados e estar disponvel para os gerentes de projetos.
92
Atributos

1. 2. Todas SEPG
RF0009 Elaborao de um plano de projeto de acordo com a Meta Especfica SG2: Elaborar Plano de Projeto e Prticas Especficas SP 2.1 a 2.4 e 2.7. Devero ser criados mecanismos para estabelecimento e manuteno do oramento e cronograma do projeto, bem como para identificao dos riscos do projeto, seu impacto, probabilidade de ocorrncia e priorizao. Um mecanismo para arquivamento e acesso aos dados dever ser implementado e os dados de identificao, forma de coleta e distribuio devero ser documentados. Recursos humanos, de materiais e de custos devero tambm ser planejados e informados em um mecanismo comum do planejamento do projeto. Atributos

1. 2. 3. Todas SEPG Consultoria
RF0010 Elaborao de um plano de conhecimentos e perfis necessrios, e de envolvimento dos stakeholders do projeto de acordo com a Meta Especfica SG2: Elaborar Plano de Projeto e Prticas Especficas SP 2.5 e 2.6. Devero ser criados um sistema de banco de dados de perfis, um inventrio de necessidades e planos de contratao. Desta forma, isto permitir maior agilidade para busca de recursos qualificados que se encontram disponveis na organizao ou para a tomada de deciso acerca da realizao de novas contrataes. Os envolvimentos dos stakeholders devero ser planejados, considerando suas responsabilidades, necessidades de recursos para garantir interaes, relacionamento etc.
93
Atributos

1. 2. Todas SEPG
RF0011 Obter comprometimento com o plano de projeto de acordo com a Meta Especfica SG3: Obter Comprometimento com o Plano de Projeto e Prticas Especficas SP 3.1 a 3.3. Dever ser estabelecido no processo atividades de reviso de planos. O comprometimento dos stakeholders dever ser documentado. Atributos

1. 2. Todas SEPG
3.2.3. Implantao da rea de Processo: Monitoramento e Controle do Projeto (PMC) RF0012 Monitorar o projeto em relao ao plano de acordo com a Meta Especfica SG1: Monitorar o Projeto em Relao ao Plano e Prticas Especficas SP 1.1 ao 1.7. Dever ser monitorado o projeto em relao ao plano. O processo dever estabelecer atividades que determinem o monitoramento do progresso em relao ao cronograma, custo e esforo empregados no projeto, recursos fornecidos e utilizados, conhecimento e habilidades do pessoal do projeto, atributos dos produtos de trabalho e das tarefas, tais como tamanho e complexidade, e identificao de desvios significativos. O processo tambm dever estabelecer atividades referentes ao monitoramento dos compromissos em relao aos identificados no plano de projeto, riscos, gesto de dados, envolvimento dos stakeholders, bem como conduzir revises de progresso e de marcos.
94
Atributos

3. 4. Todas SEPG
RF0013 Gerenciar aes corretivas at o encerramento do projeto de acordo com a Meta Especfica SG2: Gerenciar Aes Corretivas at o Encerramento e Prticas Especficas SP 2.1 ao 2.3. Dever ser descrito no processo atividades concernentes coleta e anlise dos problemas e determinao das aes corretivas para trat-los. Um plano de aes corretivas dever ser criado a fim de documentar as aes apropriadas para tratar os problemas identificados. Uma negociao sobre mudanas dever ser tratada com os stakeholders e documentada. Atributos

1. 2. Todas SEPG
3.2.4. Implantao da rea de Processo: Gesto de Acordo com os Fornecedores (SAM) RF0014 Estabelecimento de acordos com o fornecedor de acordo com a Meta Especfica SG1: Estabelecer Acordos com o Fornecedor, e Prticas Especficas SP 1.1 ao 1.3. Devero ser estabelecidas no processo orientaes para aquisies de produtos ou servios, bem como a definio de tipos de aquisies, seleo de fornecedores e mtodos para estabelecimento e manuteno de acordos formais atravs de declaraes de trabalho, contratos, memorandos ou licenas de acordo. Modelos de artefatos devero ser estabelecidos e ser acessveis aos gerentes de projetos.
95
Atributos

1. 2. 3. Todas SEPG Assessoria tcnica
RF0015 Promover a satisfao dos acordos com os fornecedores pelo projeto de acordo com a Meta Especfica SG2: Satisfazer Acordos com o Fornecedor, e Prticas Especficas SP 2.1 ao 2.5. Devero ser estabelecidas no processo orientaes sobre como executar atividades com o fornecedor conforme especificado no acordo, como o monitoramento do progresso e do desempenho, conduo de revises com os fornecedores, de revises tcnicas, revises de gerenciamento e de monitoramento dos riscos envolvendo o fornecedor. Deste modo, para os projetos sero desenvolvidos relatrios de progresso do fornecedor e medidas de desempenho, sero realizados revises de materiais e relatrios do fornecedor, acompanhamento dos itens de ao at a sua concluso e recebimento de documentaes. Os processos tambm sero monitorados e acompanhados, produtos devem ser avaliados aps a sua identificao, conferindo maior ateno aos produtos crticos para o sucesso do projeto. O processo estabelecer tambm orientaes para que seja assegurada a satisfao do acordo com o fornecedor antes de aceitar o produto adquirido. Para isto sero realizados procedimentos de teste e experimentao. Devem ser estabelecidas tambm orientaes para transferncia dos produtos adquiridos do fornecedor para o projeto, constituindo planos de transio, relatrios de treinamento, de manuteno e de suporte. Atributos

1. 2. 3. Todas SEPG Assessoria tcnica
96
3.2.5. Implantao da rea de Processo: Medio e Anlise (MA) RF0016 Alinhamento dos objetivos e atividades de medies com as necessidades e objetivos de informaes, identificados de acordo com a Meta Especfica SG1: Alinhar Atividades de Medio e Anlise e Prticas Especficas SP 1.1 ao 1.4. Devero ser estabelecidos no processo critrios para a criao e a manuteno de objetivos de medies que so derivados das necessidades e objetivos de informaes identificados. Desta forma, sero documentadas e priorizadas as necessidades de informaes, especificadas as medidas para tratar os objetivos das medies, os procedimentos de coleta e armazenamento de dados de medies e os procedimentos de anlise e disponibilidade das informaes. Atributos

1. 2. 3. 4. Todas SEPG Consutoria Assessoria tcnica
RF0017 Fornecimento dos resultados das medies de acordo com a Meta Especfica SG2: Fornecer Resultados das Medies e Prticas Especficas SP 2.1 ao 2.4. Devero ser estabelecidos mecanismos para coleta e armazenamento dos dados de medies, com o objetivo de facilitar a atividade de anlise e interpretao dos dados pelos analistas de medies ou pessoas que assumam outros papis com atribuies similares. Deste modo, devero ser construdos para um projeto, conjuntos de dados de medies bsicas e derivadas, resultados de testes de integridade de dados, de anlises e relatrios preliminares e o refinamento dos critrios para anlises futuras. Os resultados sero relatados aos stakeholders relevantes. Atributos

1. 2. Todas SEPG
97
2.1.6. Implantao da rea de Processo: Garantia da Qualidade de Processo e Produto (PPQA) RF0018 Avaliao objetiva da aderncia dos processos executados, dos produtos de trabalho e dos servios associados em relao descrio dos processos, padres e procedimentos aplicveis, de acordo com a Meta Especfica SG1: Avaliar Objetivamente Processos e Produtos de Trabalho, e Prticas Especficas SP 1.1 e 1.2. Devero ser estabelecidos no processo critrios para a avaliao dos processos escolhidos em relao descrio do processo, padres e procedimentos aplicveis atravs da utilizao de relatrios de avaliao, de no conformidades e determinao de aes corretivas. Para isto dever ser promovido um ambiente que encoraje os colaboradores a participarem na identificao e relato de problemas relacionados qualidade. Os critrios devero ser criados e mantidos para as avaliaes. Estas sero executadas periodicamente ao longo do projeto ou incrementalmente. Lies aprendidas podero ser identificadas e documentadas para consulta com o objetivo de melhorar os processos para produtos e servios futuros. Atributos

1. 2. Todas SEPG
RF0019 Rastrear problemas relativos a no conformidades e garantir a comunicao e sua soluo, de acordo com a Meta Especfica SG2: Fornecer uma Viso Objetiva, e Prticas Especficas SP 2.1 e 2.2. Devero ser estabelecidos no processo mecanismos para a comunicao dos problemas relativos qualidade, que incluem no conformidades e resultados de anlises de tendncia. Igualmente, dever ser garantida a soluo de no conformidades com a equipe e com os gerentes. Outro mecanismo dever ser construdo para manter os registros das atividades de garantia da qualidade que incluem os registros das avaliaes, relatrios da garantia da qualidade e de estado de aes corretivas. Atributos
Complexidade: Complexa Alta Risco: Alto Mdio Mdia Baixo Baixa
98
Prioridade:

1. 2. Todas SEPG
2.1.7. Implantao da rea de Processo: Gesto da Configurao (CM) RF0020 Criao das baselines dos produtos de trabalhos identificados, de acordo com a Meta Especfica SG1: Estabelecer Baselines, e Prticas Especficas SP 1.1 ao 1.3. Devero ser estabelecidos no processo um meio para documentar os itens de configurao, componentes e produtos de trabalhos identificados que sero colocados sob gesto de configurao. Esta identificao a seleo, criao e especificao dos produtos que sero entregues ao cliente, produtos de trabalho internos definidos, adquiridos, ferramentas e outros itens que so utilizados na criao e descrio destes produtos de trabalho, como documentos de especificao e interface, por exemplo. Dever ser atribudo identificadores nicos para os itens de configurao e especificado as caractersticas importantes de cada item de configurao, bem como dever ser identificado o responsvel por cada item. Um sistema de gesto de configurao dever ser estabelecido e mantido com objetivo de controlar os produtos de trabalho, bem como permitir a criao e a liberao de baselines do projeto. Outro sistema dever ser criado com o objetivo de gerenciar dados de solicitaes de alterao. Atributos

1. 2. 3. Todas SEPG Consultoria
RF0021 Controle e rastreamento das alteraes de itens de configurao, de acordo com a Meta Especfica SG2: Rastrear e Controlar Alteraes, e Prticas Especficas SP 2.1 e 2.2. Dever ser estabelecido um mecanismo para rastreamento das solicitaes de alterao para os itens de configurao, com o objetivo de permitir iniciar e registrar as solicitaes de alterao na base de dados de solicitaes de alterao, analisar o impacto das alteraes e das correes propostas, revisar as solicitaes que sero tratadas na prxima baseline com os stakeholders
99
relevantes e rastrear o estado das solicitaes de alterao at a sua concluso. Os itens de configurao devero ser controlados, mantendo para tal fim um histrico das revises. Atributos

1. 2. Todas SEPG
RF0022 Estabelecer e manter a integridade das baselines, de acordo com a Meta Especfica SG3: Rastrear e Controlar Alteraes, e Prticas Especficas SP 3.1 e 3.2. Dever ser estabelecido um registro da gesto de configurao, bem como executar auditorias de configurao com o objetivo de manter a integridade das baselines. Atributos

1. 2. Todas SEPG
2.1.8. Implantao das reas de Processos de acordo com as Metas Genricas (GG) definidas RF0023 Aderncia s prticas estabelecidas nas Metas Genricas GG2: Institucionalizar um Processo Gerenciado para todas as reas de processos do nvel de maturidade 2 do CMMI-DEV. Dever ser institucionalizado o processo de desenvolvimento de software como um processo gerenciado, estabelecendo e mantendo uma poltica organizacional e planos para execues, fornecendo recursos adequados para a execuo e elaborao dos produtos de trabalho e fornecimento dos servios dos processos, atribuio de responsabilidades, treinamento de pessoas, gerenciamento de configuraes identificao e envolvimento dos stakeholders relevantes, monitoramento e controle, e avaliao da aderncia para todos os
100
processos do nvel 2 de maturidade do CMMI-DEV, bem como realizar a reviso da situao e dos resultados do processo com a gerncia superior. Atributos

1. 2. Todas SEPG
4. Requisitos no funcionais
Esta seo descreve os requisitos no funcionais do projeto.
4.1. Infraestrutura
RNF0001 Definio da infraestrutura do SEPG Dever ser disponibilizada a infraestrutura necessria para a formao do SEPG. Devero ser disponibilizados: Um computador para cada membro com acesso internet; Impressora; Disponibilidade de uma sala de reunies com datashow; Telefone; Materiais de expediente, como papel A4 e A3, canetas, lapiseiras, rascunhos, quadro branco, mesa para modelagem de projetos, rgua etc. RNF0002 Software Devero ser disponibilizados os seguintes produtos de software, com a quantidade mnima de licenas: a. b. c. d. e. f. g. h. i. j. k. CollabNet SVN Server. Enterprise Architech, 1 licena corporativa; Microsoft Communications Server, 1 licena corporativa; Microsoft Excel, 1 licena corporativa; Microsoft PowerPoint, 1 licena corporativa; Microsoft Project Server, 1 licena; Microsoft Project, 10 licenas; Microsoft SharePoint Services Server, 1 licena; Microsoft SQL Server, 1 licena corporativa; Microsoft Visio, 2 licenas; Microsoft Word, 1 licena corporativa; 1. 2. 3. 4. 5.
101
l. Sistema Operacional Windows Server, 1 licena corporativa; m. Sistema Operacional Windows, 1 licena corporativa; n. Tortoise SVN; 4.2.
Acessibilidade
RNF0003 Acesso s informaes Dever ser disponibilizado acesso s informaes dos recursos humanos da organizao, como custos e currculos, bem como acesso s polticas e processos da organizao. RNF0004 Acessibilidade aos produtos de trabalhos gerados Dever ser disponibilizado acesso s informaes e aos produtos de trabalhos gerados de acordo com o nvel de acessibilidade de cada parte interessada do projeto. Desta forma, devero ser disponibilizados atravs de ferramentas de controle de verso e sites internos. 4.3.
Segurana
RNF0005 Segurana s informaes As informaes disponibilizadas devero ter acesso controlado de acordo com o nvel de acesso de cada parte interessada, controlado por senha. Deste modo, os gerentes das unidades, diretores, coordenadores do projeto e presidncia tero acesso s informaes de custos operacionais. Os demais tero acesso s informaes tcnicas relevantes ao desempenho de suas atividades. 4.4.
Disponibilidade
RNF0006 Disponibilidade das informaes As informaes devero estar disponibilizadas 24 horas por dia, 7 dias na semana atravs da intranet da empresa e da Internet. 4.5.
Recursos de custo
RNF0007 Transporte, hospedagem e alimentao Dever ser disponibilizado pela organizao o custeio dos gastos a serem realizados para o transporte, hospedagem e alimentao das partes interessadas envolvidas com a execuo do projeto, conforme detalhado no cronograma de planejamento. 4.6.
Padres
RNF0008 PMBOK Todo o planejamento e a execuo do projeto devero seguir as recomendaes do Guia PMBOK, 4 edio.
102
5. No-requisitos
Esta seo descreve os no-requisitos do projeto. Estes compem o escopo negativo do projeto. NR0001 Aplicao de metodologia gil para o processo de desenvolvimento Para este projeto, no sero aplicadas prticas das metodologias geis para este processo de desenvolvimento.
6. Critrios de aceitao
Os requisitos descritos neste documento sero tidos como aceitos aps a confirmao do completo entendimento por todas as partes interessadas ou seus representantes atravs do documento de Aceitao dos Requisitos. As assinaturas constaro no documento mencionado anteriormente e neste documento de requisitos.
X
Ana Beatriz Gerente de Projetos
X
Luiz Alves Assessor Tcnico da Presidncia
103
APNDICE G ACEITAO DOS REQUISITOS
104
Aceitao dos Requisitos

Aceitao n: Cliente: Responsvel: Revisor(es): 1 eGovSS Ana Beatriz, gerente de projetos Luiz Alves, assessor tcnico da presidncia Data: Limite para Entrega: Contrato: 24/01/2010 -
I. Requisitos
Utilize os seguinte itens na coluna avaliao: OK - Requisito aceito; NA - Requisito no aceito; RR - Aceito com restries
Requisito Funcional RF0001 Avaliao preliminar SCAMPI
Descrio
Avaliao
Observao
OK
RF0002
Coleta e anlise dos Indicadores de Implementao das Prticas (PII)
OK
RF0003
Formao do Grupo de Processos de Engenharia de Software (SEPG) Realizao do gerenciamento dos requisitos e identificao das inconsistncias dos produtos de trabalho com os planos de projetos de acordo com a Meta SG1: Gerenciar Requisitos e Prticas Especficas SP 1.1 e 1.2. Gerenciamento das mudanas dos requisitos medida que evoluem durante o projeto de acordo com a Meta Especfica SG1: Gerenciar Requisitos e Prtica Especfica SP 1.3. Manter a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho de acordo com a Meta Especfica SG1: Gerenciar Requisitos e Prtica Especfica SP 1.4. Identificar inconsistncias entre trabalho de projeto e requisitos de acordo com a Meta Especfica SG1: Gerenciar Requisitos e Prtica Especfica SP 1.5. Estabelecimento das estimativas de acordo com a Meta Especfica SG1: Estabelecer Estimativas e Prticas Especficas SP 1.1, 1.2, 1.3 e 1.4. Elaborao de um plano de projeto de acordo com a Meta Especfica SG2: Elaborar Plano de Projeto e Prticas Especficas SP 2.1 a 2.4 e 2.7.
OK
RF0004
OK
RF0005
OK
RF0006
OK
RF0007
OK
RF0008
OK
RF0009
RR
105
RF0010
Elaborao de um plano de conhecimentos e perfis necessrios, e de envolvimento dos stakeholders do projeto de acordo com a Meta Especfica SG2: Elaborar Plano de Projeto e Prticas Especficas SP 2.4 a 2.6. Obter comprometimento com o plano de projeto de acordo com a Meta Especfica SG3: Obter Comprometimento com o Plano de Projeto e Prticas Especficas SP 3.1 a 3.3 Monitorar o projeto em relao ao plano de acordo com a Meta Especfica SG1: Monitorar o Projeto em Relao ao Plano e Prticas Especficas SP 1.1 ao 1.7 Gerenciar aes corretivas at o encerramento do projeto de acordo com a Meta Especfica SG2: Gerenciar Aes Corretivas at o Encerramento e Prticas Especficas SP 2.1 ao 2.3 Estabelecimento de acordos com o fornecedor de acordo com a Meta Especfica SG1: Estabelecer Acordos com o Fornecedor, e Prticas Especficas SP 1.1 ao 1.3. Promover a satisfao dos acordos com os fornecedores pelo projeto de acordo com a Meta Especfica SG2: Satisfazer Acordos com o Fornecedor, e Prticas Especficas SP 2.1 ao 2.5. Alinhamento dos objetivos e atividades de medies com as necessidades e objetivos de informaes, identificados de acordo com a Meta Especfica SG1: Alinhar Atividades de Medio e Anlise e Prticas Especficas SP 1.1 ao 1.4. Fornecimento dos resultados das medies de acordo com a Meta Especfica SG2: Fornecer Resultados das Medies e Prticas Especficas SP 2.1 ao 2.4. Avaliao objetiva da aderncia dos processos executados, dos produtos de trabalho e dos servios associados em relao descrio dos processos, padres e procedimentos aplicveis, de acordo com a Meta Especfica SG1: Avaliar Objetivamente Processos e Produtos de Trabalho, e Prticas Especficas SP 1.1 e 1.2. Rastrear problemas relativos a no conformidades e garantir a comunicao e sua soluo, de acordo com a Meta Especfica SG2: Fornecer uma Viso Objetiva, e Prticas Especficas SP 2.1 e 2.2. Criao das baselines dos produtos de trabalhos identificados, de acordo com a Meta Especfica SG1: Estabelecer Baselines, e Prticas Especficas SP 1.1 ao 1.3. Controle e rastreamento das alteraes de itens de configurao, de acordo com a Meta Especfica SG2: Rastrear e Controlar Alteraes, e Prticas Especficas SP 2.1 e 2.2. Estabelecer e manter a integridade das baselines, de acordo com a Meta Especfica SG3: Rastrear e Controlar Alteraes, e Prticas Especficas SP 3.1 e 3.2. Aderncia s prticas estabelecidas nas Metas Genricas GG2: Institucionalizar um Processo Gerenciado para todas as reas de processos do nvel de maturidade 2 do CMMI-DEV.
RR
RF0011
RR
RF0012
OK
RF0013
OK
RF0014
OK
RF0015
OK
RF0016
OK
RF0017
OK
RF0018
OK
RF0019
OK
RF0020
OK
RF0021
OK
RF0022
OK
RF0023
OK
106
Requisito NoFuncional RNF0001 RNF0002 RNF0003 RNF0004 RNF0005 RNF0006 RNF0007 RNF0008 Definio da infraestrutura do SEPG Software Acesso s informaes
Descrio
Avaliao OK OK OK OK OK OK RR OK
Observao
Acessibilidade aos produtos de trabalhos gerados Segurana s informaes Disponibilidade das informaes Transporte, hospedagem e alimentao PMBOK
II. Produtos e servios a serem entregues

Produto/Servio Processo de Desenvolvimento de Software Modelos de artefatos necessrios execuo das atividades do processo Definio de papis, contendo atribuies, responsabilidades e requisitos para contrao Sistemas de banco de dados de requisitos e de rastreabilidade Sistemas de comunicao Implantao de sistemas servidores de banco de dados, distribuio de informaes (sites) e de projetos Implantao de sistema de controle de verso Realizao de treinamentos em gerenciamento de projetos, de configurao, aquisies, medio e anlise, qualidade de processo e de produto Avaliao OK OK OK OK OK OK OK OK Observao
III. Concluso
Aceito integralmente Aceito com restries No-aceito

IV. Observaes
____________________________________________ Ana Beatriz

Gerente de Projetos
____________________________________________ Luiz Alvez

Assessor Tcnico da Presidncia
107
APNDICE H MATRIZES DE RASTREABILIDADE
108
Matriz de Rastreabilidade
Entre Requisitos Funcionais
RF0001
RF0002
RF0003
RF0004
RF0005
RF0006
RF0007
RF0008
RF0009
RF0010
RF0011
RF0012
RF0013
RF0014
RF0015
RF0016
RF0017
RF0018
RF0019
RF0020
RF0021
RF0022
RF0001 RF0002 RF0003 RF0004 RF0005 RF0006 RF0007 RF0008 RF0009 RF0010 RF0011 RF0012 RF0013 RF0014 RF0015 RF0016 RF0017
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
X X
X X X
X X X
X X X X
X X
X X
X X
X X
X X
X X
X X X X X
X X X X X X
X X X X X X X X X X
X X X X X X X X X X X X
X X
X X
X X
X X
X X
X X X X
X X X
X X X X X
X X X X X
X X X X
X X X X
X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X
X X
X X
X X
X X X X X X X X X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
RF0023
X X X X X X X X X X X X X X X X X
109
RF0018 RF0019 RF0020 RF0021 RF0022 RF0023
X X X X X X
X X X X X X
X X X X
X X X X X X X
X X X X X
X X X X X
X X X X X
X X X
X X X X X
X X X X
X X X X
X X X X X X X X X X
110
Matriz de Rastreabilidade
Entre Requisitos Funcionais e No Funcionais
RNF0001 RNF0002 RNF0003 RNF0004 RNF0005 RNF0006 RNF0007 RNF0008
RF0001 RF0002 RF0003 RF0004 RF0005 RF0006 RF0007 RF0008 RF0009 RF0010 RF0011 RF0012 RF0013 RF0014 RF0015 RF0016 RF0017 RF0018 RF0019 RF0020 RF0021 RF0022 RF0023
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
111
APNDICE I PLANO DE GERENCIAMENTO DE REQUISITOS
112
Plano de Gerenciamento de Requisitos

113
Contedo
1. Introduo............................................................................................................................................ 114
1.1. 1.2. Definies, acrnimos e abreviaes ............................................................................................... 114 Referncias ....................................................................................................................................... 114
2.
Gerenciamento dos requisitos ............................................................................................................. 114

2.1. 2.2. 2.3. Planejamento das atividades de gesto de requisitos ..................................................................... 114 Priorizao dos requisitos ................................................................................................................ 115 Rastreabilidade dos requisitos ......................................................................................................... 116
114
Plano de Gerenciamento de Requisitos

1. Introduo
A finalidade deste plano de gerenciamento de requisitos documentar como os mesmos sero analisados, documentados e gerenciados do incio ao fim do projeto.
1.1. Definies, acrnimos e abreviaes

1.2. Referncias
Aceitao de Requisitos, disponvel em http://www.egovss.com.br/intra/sepg/P001/04b.Aceitao de Requisitos.xlsx Cronograma do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/03b.Cronograma do Projeto.mpp Declarao do Trabalho do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01a.Declarao do Trabalho do Projeto.docx Registro das Partes Interessadas, disponvel em http://www.egovss.com.br/intra/sepg/P001/02a.Registro das partes interessadas.xlsx Requisitos do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/04a.Requisitos do Projeto.docx Termo de Abertura do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01.Termo de Abertura de Projeto.docx
2. Gerenciamento dos requisitos

Esta seo apresenta uma descrio de como o as atividades de gesto de requisitos sero realizadas, bem como os requisitos sero priorizados e rastreados.
2.1. Planejamento das atividades de gesto de requisitos

Os requisitos sero levantados durante a fase de planejamento do projeto aps a identificao e anlise das partes interessadas. Dever ser levado em considerao o nvel
115
de influncia e de conhecimento das partes interessadas, pois uma pessoa que possui nvel de influncia significativa tem autoridade maior sobre as tomadas de decises. Pessoas que possuem alto nvel de conhecimento devero ser consultadas. O levantamento ser realizado baseando-se nas metas e prticas descritas no Capability Maturity Model Integration for Development (CMMI-DEV) v 1.2, nvel 2 de maturidade, e nas entregas determinadas para cada meta e prtica mencionada, conforme determinado nas descries dos requisitos e na estrutura de composio de trabalho (WBS) desenvolvida para o projeto. O gerenciamento de mudanas ser realizado durante a execuo de todo o projeto. Cada solicitao de mudana dever ser avaliada quanto ao impacto, riscos, viabilidade tcnica, oramentria e de esforo, sendo encaminhada para aceitao do cliente acerca do entendimento e confirmado o comprometimento das partes interessadas para com o sucesso do projeto. Para isto ser utilizado o documento de Requisitos do Projeto e de Aceitao de Requisitos. Os nveis de autorizao das partes interessadas para aprovao das mudanas so determinados de acordo com o impacto provocado no oramento, no custo, no prazo, na qualidade, na disponibilidade de recursos e na viabilidade tcnica, de acordo com a tabela abaixo:
Impacto Oramento e custos Prazos Qualidade Disponibilidade de recursos
Partes interessadas consultadas
Prazo mximo para resposta a aceitao
Para respostas fora do prazos, escalonar para: Patrocinador Assessoria tcnica Assessoria tcnica Assessoria tcnica
Diretoria financeira e 10 dias teis assessoria tcnica Assessoria tcnica e patrocinador Gerentes das unidades 5 dias teis Gerentes das unidades 3 dias teis 3 dias teis
Membros do Viabilidade tcnica worktime e consultoria
Devido ao risco de haver indisponibilidade das partes interessadas realizarem a anlise para aceitao em tempo hbil, o problema ser escalonado para a parte interessada imediatamente superior.
2.2. Priorizao dos requisitos

A priorizao dos requisitos ser determinada de acordo com a sequencialidade comum para a execuo dos procedimentos de implantao da melhoria de processos, conforme consta no documento de Requisitos de Projeto e no Cronograma do Projeto.
116 2.3. Rastreabilidade dos requisitos

A rastreabilidade dos requisitos ser determinada de forma a estabelecer um vnculo de dependncia entre os requisitos, de forma que esta informao auxiliar na anlise de impacto sobre as mudanas solicitadas de um requisito e como esta mudana influenciar em outros requisitos do projeto. Os atributos de cada requisito esto descritos no documento de Requisitos do Projeto.
117
APNDICE J DECLARAO DO ESCOPO DO PROJETO
118
Declarao do Escopo do Projeto

119
Contedo
1. Introduo............................................................................................................................................ 120
1.1. 1.2. Definies, acrnimos e abreviaes ............................................................................................... 120 Referncias ....................................................................................................................................... 120
2. 3. 4. 5. 6.
Descrio do escopo do produto ......................................................................................................... 120 Entregas do projeto ............................................................................................................................. 121 Excluses do projeto ............................................................................................................................ 122 Restries ............................................................................................................................................. 122 Premissas ............................................................................................................................................. 123
120
Declarao do Escopo do Projeto

1. Introduo
A finalidade desta declarao do escopo documentar os objetivos do projeto, as entregas e o trabalho necessrio para produzir as entregas de tal modo que essas informaes possam ser utilizadas para orientar o trabalho da equipe do projeto e tambm servir como uma base para futuras decises.

1.2. Referncias
2. Descrio do escopo do produto

A descrio do escopo do produto est contida no Termo de Abertura do Projeto.
121
3. Entregas do projeto
As entregas para este projeto so definidas abaixo:
N 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Requisito RF0001 RF0001 RF0001 RF0001, RF0002 RF0001, RF0002 RF0001, RF0002 RF0003 RF0003 RF0003 RF0004 RF0004 RF0004 RF0005, RF0006 RF0007 RF0008 RF0008 RF0008, RF0009 RF0008, RF0009, RF0010 RF0008, RF0009, RF0012 RF0008, RF0012, RF0013 RF0008, RF0009, RF0012 RF0008, RF0010 RF0008, RF0010, RF0011, RF0013, RF0018 RF0009, RF0020 RF0009, Descrio do produto ou servio Realizao da avaliao SCAMPI para aderncia do processo atual. Modelos dos processos atuais Registro da confirmao do processo modelado Registros dos Indicadores de Implementao das Prticas (PIIs). Prticas Especficas do nvel 2 de maturidade. Registros dos Indicadores de Implementao das Prticas (PIIs). Prticas Genricas do nvel 2 de maturidade. Planilha de Consolidao de Dados Formar e institucionalizar o SEPG Implantao do sistema de diagramao: Microsoft Visio Implantao do sistema de diagramao UML: Enterprise Architech Modelo da lista de critrios para seleo e distino de fornecedores de requisitos do projeto e para a avaliao e aceitao dos requisitos, mais o resultado das anlises em relao a estes critrios. Modelo de documento de aceitao e comprometimento com os requisitos Modelo de documento para realizao de anlise de impacto e de viabilidade dos requisitos Sistema de gesto de requisitos Modelo de documento para registro das inconsistncias entre produtos de trabalho e requisitos Sistema de estimativas Modelo de ciclo de vida padro Implantao do servidor de dados: SQL Server Implantao do servidor de compartilhamento e publicaes: SharePoint Services Implantao do servidor de projetos: Project Server Implantao de software cliente de planejamento e acompanhamento de projetos: Project Professional Implantao de software de planilha eletrnica: Microsoft Excel Sistema de registro de perfis dos recursos humanos Qtd. 1 4 4 56 10 7 1 2 65 1 1 1 1 1 1 1 1 1 Categoria Servio Produto Produto Produto Produto Produto Servio Produto Produto Produto Produto Produto Produto Produto Produto Produto Produto Produto
19
Produto
20
10
Produto
21 22
65 1
Produto Produto
23
Implantao de software de processamento de textos: Microsoft Word
65
Produto
24 25
Implantao do sistema de controle de verso: SVN Server Implantao do sistema de controle de verso: clientes
1 65
Produto Produto
122
RF0020 RF0009, RF0012 RF0010 RF0010 RF0012 RF0012 RF0013 RF0014 RF0014 RF0016, RF0017 RF0017, RF0019 RF0017, RF0019 RF0018 RF0018 RF0019 RF0019 RF0019 RF0023 RF0023 Todos Todos Todos Todos
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Modelo de Plano de Projeto Implantao do servio de comunicao: Communications Server Implantao dos clientes de comunicao: Communicator Modelo de registro de acompanhamento do projeto Modelo de atas de reunio e kick-off Modelo de registro das aes corretivas do acompanhamento de projetos Modelo contendo lista de tipos de aquisio e fornecedores Modelo de documento para solicitao de materiais e servios Mecanismo para coleta, armazenamento da medio e anlise baseado no PSM Implantao de sistema de apoio para anlise de negcios e tomada de decises (BI) Disponibilizao dos dados de acordo com os nveis de acesso e interesses Mecanismo para coleta e armazenamento de dados da auditoria da qualidade Modelo de lies aprendidas Mecanismo para manter os registros das avaliaes, relatrios da garantia da qualidade e de estado de aes corretivas Sistema de controle e acompanhamento de solicitaes de alterao Adequaes ao sistema de controle de verso Modelo de poltica organizacional Realizao de treinamentos Modelagem do processo de desenvolvimento de software Especificao das atividades do processo de desenvolvimento de software Especificao dos papis e artefatos do processo de desenvolvimento de software Realizar avaliao SCAMPI, obter selo de comprovao para a maturidade
1 1 65 1 1 1 1 1 1 1 1 1 1 1 1 1 1 20 1 1 1 1
Produto Produto Produto Produto Produto Produto Produto Produto Produto Produto Servio Produto Produto Produto Produto Servio Produto Servio Produto Produto Produto Servio
4. Excluses do projeto
As excluses para este projeto so definidas abaixo:
N Requisito Descrio do produto ou servio No aplicvel at o momento Qtd. Categoria
5. Restries
As seguintes restries so aplicveis ao projeto:
Categoria Escopo Oramento Recursos humanos Recursos humanos Tecnologia Tempo Descrio da restrio O escopo somente poder ser reduzindo mediante aprovao da consultoria. O oramento do projeto de R$ 350.000,00 A quantidade de recursos humanos poder comprometer o projeto. A disponibilidade dos recursos humanos poder comprometer o projeto devido a alta demanda de servios que os mesmos utilizam. As solicitaes para o desenvolvimento de novos sistemas de apoio atrasaro o projeto. O projeto tem o prazo de 2,5 anos para concluso do projeto de implantao
123
6. Premissas
As seguintes premissas so aplicveis ao projeto: A disponibilidade de reservas oramentrias imediata; A aceitao para a realizao de treinamentos ser aprovada; A disponibilidade de recursos chaves para a realizao de atividades essenciais incerta; O baixo interesse dos gerentes de unidades ao incio do projeto afetar o seu desempenho; A probabilidade da no aceitao das solicitaes inerentes ao projeto por parte da alta administrao baixa; O apoio do patrocinador e da assessoria tcnica certo; A execuo das atividades da consultoria sero produtivas e bastante contributivas e no provocaro atrasos; A organizao ir ser avaliada positivamente e ir obter o selo de qualificao.
125
APNDICE K ESTRUTURA ANALTICA DO PROJETO (WBS)

Implantao do CMMI-DEV L2 1. Iniciao 1.1. Treinamento 1.2. Formar e institucionalizar SEPG 1.2.1. Infraestrutura 1.2.1.1. 1.2.1.2. 1.2.1.3. 1.2.1.4. 1.2.2. Time 1.3. Diagnstico 1.3.1. Modelos dos processos atuais 1.3.2. Registros PIIs 1.3.2.1. 1.3.2.2. 1.3.2.3. 1.4. Nivelamento 1.4.1.1. 2. Design 2.1. Maturao dos processos 2.1.1. REQM 2.1.1.1. 2.1.1.2. Treinamentos Plano de ao Processo unificado Prticas Especficas Prticas Genricas Planilha de Consolidao de Dados Hardware de apoio Software de apoio Servidor de banco de dados Servidor de compartilhamento e publicaes
126 2.1.1.3. 2.1.1.4. 2.1.1.5. 2.1.1.6. 2.1.1.7. 2.1.1.8. 2.1.1.9. 2.1.2. PP 2.1.2.1. 2.1.2.2. 2.1.2.3. 2.1.2.4. 2.1.2.5. 2.1.2.6. 2.1.2.7. 2.1.2.8. 2.1.2.9. Treinamentos Plano de ao Execuo do plano de ao Infraestrutura Servidor de projetos Ferramenta de gerenciamento de projetos Software de processamento de textos e planilha eletrnica Servio de controle de verso Servios de comunicao Execuo do plano de ao Sistema de gesto de requisitos Construo de modelos Aceitao dos requisitos Documento anlise de impacto e de viabilidade dos requisitos Registro de inconsistncias Seleo de fornecedores e critrios de avaliao e aceitao
2.1.2.10. Construo de sistemas de apoio 2.1.2.11. Sistema de estimativas 2.1.2.12. Sistema de registro de perfis 2.1.2.13. Construo de modelos 2.1.2.14. Ciclo de vida 2.1.2.15. Plano de projeto 2.1.3. PMC 2.1.3.1. 2.1.3.2. Treinamentos Plano de ao
127 2.1.3.3. 2.1.3.4. 2.1.3.5. 2.1.3.6. 2.1.3.7. 2.1.4. SAM 2.1.4.1. 2.1.4.2. 2.1.4.3. 2.1.4.4. 2.1.4.5. 2.1.4.6. 2.1.5. MA 2.1.5.1. 2.1.5.2. 2.1.5.3. 2.1.5.4. 2.1.5.5. 2.1.5.6. 2.1.5.7. 2.1.5.8. 2.1.6. PPQA 2.1.6.1. 2.1.6.2. 2.1.6.3. 2.1.6.4. Treinamentos Plano de ao Execuo do plano de ao Construo de sistemas de apoio Treinamentos Plano de ao Execuo do plano de ao Infraestrutura Servidor de sistema de apoio anlise de negcio (BI) Construo de sistemas de apoio Sistema de coleta, armazenamento e anlise da medio Disponibilizao dos dados Treinamentos Plano de ao Execuo do plano de ao Construo de modelos Registro dos fornecedores Documento de solicitao de materiais e servios Execuo do plano de ao Construo de modelos Registro de acompanhamento de projetos Aes corretivas Atas de reunio
128 2.1.6.5. 2.1.6.6. 2.1.6.7. 2.1.6.8. 2.1.6.9. 2.1.7. CM 2.1.7.1. 2.1.7.2. 2.1.7.3. 2.1.7.4. 2.1.7.5. 2.1.7.6. 3. Piloto 3.1. Preparao 3.2. Execuo 3.3. Monitoramento 3.4. Anlise dos resultados 3.4.1. Atualizao dos procedimentos 4. Implementao 4.1. Preparao 4.2. Execuo 4.3. Monitoramento 4.4. Consolidao dos processos 4.5. Encerramento 4.5.1. Lies aprendidas 5. Avaliao Treinamentos Plano de ao Execuo do plano de ao Infraestrutura Solicitaes de alterao Adequaes ao sistema de controle de verso Coleta e armazenamento de dados de auditoria da qualidade Registro das aes corretivas Relatrios da garantia da qualidade Construo de modelos Lies aprendidas
129 5.1. Seleo dos avaliadores 5.2. Simulado 5.3. Avaliao 6. Avaliao dos resultados e lies aprendidas
130
APNDICE L CRONOGRAMA DO PROJETO
131
132
133
134
135
136
137
138
139
APNDICE M LINHA DE BASE DE CUSTOS DO PROJETO

Dados Gerais
Ano 2010 Ms Fevereiro Maro Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro Maro Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro Custo
R$ 29.479,23 R$ 15.497,20 R$ 15.666,05 R$ 17.285,94 R$ 9.287,13 R$ 12.912,32 R$ 13.217,34 R$ 17.027,37 R$ 14.690,47 R$ 10.093,12 R$ 9.480,00 R$ 4.763,00 R$ 11.545,00 R$ 9.853,00 R$ 5.037,00 R$ 9.934,22 R$ 8.320,12 R$ 493,50 R$ 4.259,50 R$ 19.027,30 R$ 21.103,30 R$ 19.013,95 R$ 6.609,50 R$ 22.704,00 R$ 5.144,00
Custo Acumulado
R$ 29.479,23 R$ 44.976,43 R$ 60.642,48 R$ 77.928,42 R$ 87.215,55 R$ 100.127,87 R$ 113.345,21 R$ 130.372,58 R$ 145.063,05 R$ 155.156,17 R$ 164.636,17 R$ 169.399,17 R$ 180.944,17 R$ 190.797,17 R$ 195.834,17 R$ 205.768,39 R$ 214.088,51 R$ 214.582,01 R$ 218.841,51 R$ 237.868,81 R$ 258.972,11 R$ 277.986,06 R$ 284.595,56 R$ 307.299,56 R$ 312.443,56
Requisitos de Financiamento
R$ 60.642,48 R$ 60.642,48 R$ 60.642,48 R$ 100.127,87 R$ 100.127,87 R$ 100.127,87 R$ 145.063,05 R$ 145.063,05 R$ 145.063,05 R$ 169.399,17 R$ 169.399,17 R$ 169.399,17 R$ 195.834,17 R$ 195.834,17 R$ 195.834,17 R$ 214.582,01 R$ 214.582,01 R$ 214.582,01 R$ 258.972,11 R$ 258.972,11 R$ 258.972,11 R$ 307.299,56 R$ 307.299,56 R$ 307.299,56 R$ 312.443,56
Valor Liberao
R$ 60.642,48
R$ 39.485,39
R$ 44.935,18
2011
R$ 24.336,12
R$ 26.435,00
R$ 18.747,84
R$ 44.390,10
2012
R$ 48.327,45 R$ 5.144,00
R$ 100.000,00
R$ 150.000,00
R$ 200.000,00
R$ 250.000,00
R$ 300.000,00
R$ 350.000,00
Valores R$ 50.000,00 R$ 0,00
2010 2011 2012

Custo Custo Acumulado Requisitos de Financiament o
Fevereiro Maro Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro Maro Abril Maio Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro
140
141
APNDICE N PLANO DE QUALIDADE E MTRICAS DO PROJETO
142

143
Contedo
1. Introduo.................................................................................................................................. 144
1.1. 1.2. Definies, acrnimos e abreviaes .....................................................................................144 Referncias .............................................................................................................................144
2.
Gerenciamento da qualidade .................................................................................................... 145

2.1. Tarefas e responsabilidades ...................................................................................................145
2.1.1. Papis e responsabilidades ....................................................................................................145 2.1.2. Processo de Gesto da Qualidade e Cronograma ..................................................................146
3. 4. 5. 5.1. 5.2.
Padres, normas e diretrizes ..................................................................................................... 146 Mtricas de Qualidade ............................................................................................................... 146 Plano de Reviso e Auditoria ..................................................................................................... 149 Programao .............................................................................................................................. 149 Resoluo de Problemas e Ao Corretiva ................................................................................ 149
144

1. Introduo
O objetivo da Garantia de Qualidade assegurar que a execuo dos processos, artefatos e servios sejam avaliadas objetivamente de acordo com os padres e procedimentos aplicveis, assegurando que as no conformidades sejam corrigidas e provendo, com visibilidade adequada, um feedback para a equipe do projeto.

1.2. Referncias
Aceitao de Requisitos, disponvel em http://www.egovss.com.br/intra/sepg/P001/04b.Aceitao de Requisitos.xlsx Cronograma do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/03b.Cronograma do Projeto.mpp Declarao do Trabalho do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01a.Declarao do Trabalho do Projeto.docx Registro das Partes Interessadas, disponvel em http://www.egovss.com.br/intra/sepg/P001/02a.Registro das partes interessadas.xlsx Requisitos do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/04a.Requisitos do Projeto.docx Termo de Abertura do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01.Termo de Abertura de Projeto.docx Modelo de Informao para Medio, disponvel em http://www.egovss.com.br/intra/sepg/P001/08c.Modelo de Informao para Medio.docx Poltica Organizacional, disponvel em http://www.egovss.com.br/intra/sepg/P001/08b.Poltica Organizacional.docx
145
2. Gerenciamento da qualidade
Esta seo apresenta uma descrio de como o as atividades de gesto de qualidade sero realizadas.
2.1. Tarefas e responsabilidades 2.1.1. Papis e responsabilidades

Os papis e as responsabilidades para a execuo da garantia da qualidade descrito na tabela abaixo:
Tabela 11 - Papis e responsabilidades
Papis Coordenador do projeto
Responsabilidades Criar e manter o Plano da Qualidade; Supervisionar e conduzir auditorias no processo e no produto de software; Estabelecer e manter medies segundo as necessidades de informao de processos tcnicos e gerenciais; Estabelecer aes corretivas para no-conformidades e acompanh-las at as suas efetivas concluses; Aprovar entrega de releases como definido no Plano de Gerenciamento do Projeto; Revisar os produtos de trabalho; Manter a conformidade e aderncia do processo estabelecido. Apoiar a coordenao do projeto na execuo das suas tarefas; Resolver quaisquer recomendaes e no conformidades levantadas pela coordenao do projeto; Revisar o Plano de Qualidade.
Campeo
146
2.1.2. Processo de Gesto da Qualidade e Cronograma

O processo da qualidade no projeto de Implantao do CMMI-DEV L2 representado abaixo:
Revises em marcos
Ana Beatriz, coordenadora
Auditorias do Processo
Ana Beatriz, coordenadora do projeto
Revises do Processo
Ana Beatriz, coordenadora do projeto Luiz Alves, campeo
Figura 8 - Processo de atividades da Garantia da Qualidade
A execuo das atividades do processo sero executadas ao fim de cada iterao estabelecido no Plano de Gerenciamento de Projeto.
3. Padres, normas e diretrizes

Esta seo faz referncia aos padres, normas e diretrizes que sero usados no projeto e onde eles estaro armazenados. A tabela 2 abaixo lista estas informaes:
Tabela 12 - Padres, normas e diretrizes
Padro, norma ou diretriz PMBOK 4 CMMI para Desenvolvedores, v1.2, nvel 2 de maturidade
Descrio Contm normas sobre os procedimentos para planejamento e acompanhamento deste projeto. Contm diretrizes sobre as prticas que devero ser observadas para o gerenciamento e monitoramento de projetos de desenvolvimento de software, gesto de requisitos, de acordo com fornecedores, de configurao, medio e anlise e garantia da qualidade de processo e de produto. Contm diretrizes e mtodos para avaliao padro CMMI para melhoria de processos. Define e reafirma as diretrizes da empresa com relao aos padres adotados.
SCAMPI v.1.1. Poltica Organizacional
Todas estas informaes podero ser encontradas no repositrio de recursos adicionais do projeto.
4. Mtricas de Qualidade
Esta seo descreve as mtricas de qualidade do processo que sero capturadas e monitoradas para o projeto. As medies sero realizadas atravs do mtodo definido pela Practical Software and Systems Measurement (PSM) utilizando o Modelo de Informao para Medio.
147
Algumas necessidades de informaes podero ser levantadas de acordo com as questes candidatas abaixo, enquadradas em suas respectivas categorias:
Tabela 13 Questes candidatas
Categorias
Conceitos Mensurveis
Questes candidatas Quanto ir custar este projeto? Qual ser o impacto da no realizao deste projeto? Qual os benefcios financeiros que ns alcanaremos? Isto ir melhorar a nossa fora de trabalho? Isto ir ajudar na utilizao de nossos recursos? Isto ir ajudar na satisfao dos nossos colaboradores? Isto ir melhorar a nossa capacidade de gerenciamento? Isto ir melhorar a satisfao dos nossos clientes? Isto ir reduzir a quantidade de requisies de suporte ao usurio? Ser que isto vai melhorar a nossa capacidade de cumprir os objetivos ou as necessidades dos clientes? Ser que isto vai melhorar o nosso tempo de mercado? Ser que isto vai melhorar a qualidade do nosso produto ou servio? Ser que isto vai reduzir o custo da qualidade? Isto ir melhorar nossa habilidade de gerenciar objetivamente?
Financeiro
Aprendizagem e crescimento
Resultado da Melhoria de Processo
Satisfao dos clientes
Processo de negcio interno
As medidas bsicas e derivadas a serem utilizadas so listadas na tabela abaixo:

Tabela 14 Medidas bsicas e derivadas
Categorias
Conceitos Mensurveis
Medidas bsicas e derivadas Custo o Montante investido (projeto, oramento e outros custos, incluindo esforo pessoal) o Custo de oportunidade (perda de receita ou outros custos adicionais que no foram evitados, por no gastar tempo ou dinheiro com este ou outro esforo) Nvel de experincia (por exemplo,
Resultado da Melhoria de Processo
Financeiro
Aprendizagem
148
e crescimento Processo de negcio interno
Satisfao dos clientes
quantidade de certificaes, graduaes, anos de experincia, domnio de conhecimento) Nvel da equipe (quantidade de colaboradores, gerentes) Rotatividade de pessoal Avaliaes de satisfao (pesquisa de satisfao) Relatrios de problemas (caixa de sugestes, comentrios conversas pessoais) Avaliaes de satisfao Relatrios de problemas (quantidade de solicitaes ou chamadas de servio) Esforo (horas de suporte) Agregao de todas as medies padres de projeto de acordo com o interesse da organizao (por exemplo, cronograma e progresso, recursos e custo, desempenho do processo, satisfao do usurio) Medidas derivadas de outras medies de processo (custo da qualidade)
O Custo da Qualidade baseado no esforo (tempo) do trabalho realizado na organizao, com o objetivo de medir o retrabalho. Possui quatro dimenses: 7. Custo de Desempenho: custo para desenvolver e providenciar um produto ou servio, baseado nas atividades que so executadas de acordo com o plano. 8. Custo de Preveno: custo para estabelecer e manter processos e treinamentos para execuo do trabalho. 9. Custo de Avaliao: custo para reviso dos produtos e servios sob desenvolvimento, estar certo de que os requisitos sero aceitos e que haja conformidade com o processo. 10. Custo de No Conformidade (Retrabalho): custo incorrido para lidar com defeitos no produto ou servio, incluindo retrabalho no desenvolvimento do produto, reteste, revises etc, bem como o custo de suporte ao cliente, pagamento de penalidades ou multas e outros custos associados aos efeitos dos defeitos. Os artefatos gerados para possibilitar o levantamento e a anlise dos dados esto estabelecidos no repositrio que contm o Modelo de Informao para Medio.
149
5. Plano de Reviso e Auditoria

Sero realizadas revises e auditorias para garantir a aderncia do processo da empresa aos padres estabelecidos.
5.1.
Programao
As revises e auditorias sero realizadas ao trmino de cada marco, especificados de acordo com o Plano de Gerenciamento do Projeto, seguindo os processos determinados neste documento.
5.2.
Resoluo de Problemas e Ao Corretiva
Os procedimentos para correo de problemas encontrados na reviso e na auditoria so descritos na Poltica Organizacional relativo s aes descritas na seo Processo de Garantia da Qualidade.
151
APNDICE O MODELO DE INFORMAO PARA MEDIO

Nome da Medio
Verso 1.0
Descrio da Necessidade da Informao

Necessidade da Informao Categoria da Informao
Conceito Mensurvel
Conceito Mensurvel
Entidades e Atributos
Entidades Relevantes Atributos
Medida Bsica
Medidas Bsicas Mtodos de Medio Tipo do Mtodo Escala Tipo de Escala Unidade de Medio
Medida Derivada
Medida Derivada Funo
Indicador
Descrio do Indicador e Exemplo Modelo de Anlise Critrio de Deciso Interpretao do Indicador
Procedimento de Coleta de Dados (para cada Medida Bsica)

Freqncia da Coleta Responsabilidade Qual Fase ou Atividade os dados foram coletados? Ferramentas usadas na Coleta os Dados
152
Verificao e Validao Repositrio para Coleta dos Dados
Procedimento para Anlise dos Dados (para cada Indicador)

Freqncia do Relatrio de Dados Indivduo Responsvel Qual Fase ou Atividade realizada a Anlise? Ferramentas usadas na Anlise Reviso, Relatrio ou Usurio
Informao Adicional
Orientao Adicional de Anlise Consideraes de Implementao
153
APNDICE P PLANO DE RECURSOS HUMANOS
155
Plano de Recursos Humanos

156
Contedo
1. Introduo.................................................................................................................................. 157
2. 2. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.
Papis e responsabilidades ........................................................................................................ 158 Organograma do Projeto ........................................................................................................... 159 Plano de Gerenciamento de Pessoal ......................................................................................... 159 Mobilizao de Pessoal .............................................................................................................. 159 Calendrio de Recursos.............................................................................................................. 159 Necessidades de Treinamentos ................................................................................................. 159 Reconhecimento e Recompensas .............................................................................................. 159 Conformidade ............................................................................................................................ 160 Reconhecimento e Recompensas .............................................................................................. 160
157
Plano de Recursos Humanos

1. Introduo
O objetivo deste plano documentar e as funes e responsabilidades dos indivduos e grupos envolvidos nos diversos elementos do projeto, demonstrando as relaes de subordinao para cada um deles.
1.1.
Definies, acrnimos e abreviaes

1.2. Referncias
158
2. Papis e responsabilidades
Esta seo apresenta uma descrio dos papis, suas responsabilidades, competncias e autoridade para este projeto.
Tabela 15 - Papis e responsabilidades
Papis Coordenador do projeto
Responsabilidades
Autoridade Tomar decises gerenciais; Direcionar equipes e pessoas que comporo o worktime do projeto; Alocar e desalocar recursos para o projeto;
Competncia Liderana; Objetividade e responsabilidade para tomada de decises; Conhecimento em Engenharia de Software; Conhecimento em CMMI-DEV; Conhecimento sobre a poltica organizacional da organizao.
Campeo
Realizar o planejamento e o acompanhamento do projeto; Revisar os produtos de trabalho; Realizar atividades constantes conforme o planejamento da qualidade de processo e produto; Manter a conformidade e aderncia do processo estabelecido. Estabelecer e manter medies segundo as necessidades de informao de processos tcnicos e gerenciais; Estabelecer aes corretivas para no conformidades e acompanh-las at as suas efetivas concluses; Fornecer feedback para a alta gerncia. Apoiar a coordenao do projeto na execuo das suas tarefas; Resolver quaisquer recomendaes e no conformidades levantadas pela coordenao do projeto; Resolver conflitos; Gerenciar expectativas da presidncia e demais diretorias; Avaliar desempenho das atividades. Direcionar, avaliar e acompanhar atividades da coordenao do projeto e demais membros do worktime; Realizar atividades conforme planejadas pela coordenao do projeto; Realizar atividades conforme planejadas pela coordenao do projeto;
Consultoria
Acompanhar, avaliar, apoiar, intervir, intermediar e motivar coordenao e membros do worktime do projeto; Estabelecer metas para atendimento s expectativas.
Liderana; Objetividade e responsabilidade para tomada de decises; Conhecimento basilar em Engenharia de Software; Conhecimento sobre a poltica organizacional da organizao. N/A
N/A
Membro do Worktime
N/A
Analista de suporte
N/A
Conhecimento tcnico necessrio para execuo de suas atividades. Conhecimento tcnico necessrio para execuo de suas atividades.
159
3.
Organograma do Projeto
Esta seo faz referncia ao organograma do projeto, de acordo com os papis e responsabilidades definidos neste plano.
Campeo
Coordenao
Consultoria
Analista de suporte
Membro do Worktime
Membro do Worktime
...
Membro do Worktime
Figura 9 - Organograma do Projeto
4. Plano de Gerenciamento de Pessoal

Este plano documenta como e quando os recursos humanos entram e saem do projeto.
4.1.
Mobilizao de Pessoal
Os integrantes da equipe para este projeto sero solicitados aps a aprovao do plano de projeto pelos interessados. Sua disponibilizao ser comunicada em no mnimo 5 dias teis anteriores ao incio das atividades para os quais foram alocados. Os integrantes estaro localizados nas suas respectivas equipes, sob a gerncia dos Gerentes de Unidade.
4.2. Calendrio de Recursos

Informaes sobre a disponibilidade dos recursos esto localizadas no Histograma de Recursos, no Cronograma do Projeto, visualizao de Grfico de Recursos.
4.3. Necessidades de Treinamentos

As necessidades de treinamentos esto descritos no Cronograma do Projeto, bem como o esforo necessrio, os custos e a necessidade de disponibilizao de recursos humanos, de materiais e de custos para cada treinamento a ser realizado.
4.4. Reconhecimento e Recompensas

Est sendo avaliada pela a diretoria a realizao de um jantar especial para todos os integrantes do projeto aps a avaliao positiva da implantao.
160
4.5.
Conformidade
No se aplica no momento.
4.6.
Reconhecimento e Recompensas
No se aplica no momento.
161
APNDICE Q PLANO DE GERENCIAMENTO DOS RISCOS
163
Plano de Gerenciamento dos Riscos

164
Contedo
1. Introduo.................................................................................................................................. 157
2. 2. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.
Papis e responsabilidades ........................................................................................................ 158 Organograma do Projeto ........................................................................................................... 159 Plano de Gerenciamento de Pessoal ......................................................................................... 159 Mobilizao de Pessoal .............................................................................................................. 159 Calendrio de Recursos.............................................................................................................. 159 Necessidades de Treinamentos ................................................................................................. 159 Reconhecimento e Recompensas .............................................................................................. 159 Conformidade ............................................................................................................................ 160 Reconhecimento e Recompensas .............................................................................................. 160
165
Plano de Gerenciamento dos Riscos

1. Introduo
O objetivo deste plano especificar como os riscos sero definidos, monitorados e controlados ao longo do projeto.

1.2. Referncias
Aceitao de Requisitos, disponvel em http://www.egovss.com.br/intra/sepg/P001/04b.Aceitao de Requisitos.xlsx Cronograma do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/03b.Cronograma do Projeto.mpp Declarao de Escopo do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/05a.Declarao do Escopo do Projeto.docx Declarao do Trabalho do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01a.Declarao do Trabalho do Projeto.docx Registro das Partes Interessadas, disponvel em http://www.egovss.com.br/intra/sepg/P001/02a.Registro das partes interessadas.xlsx Requisitos do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/04a.Requisitos do Projeto.docx Termo de Abertura do Projeto, disponvel em http://www.egovss.com.br/intra/sepg/P001/01.Termo de Abertura de Projeto.docx
166
2. Funes e Responsabilidades
A equipe responsvel pela administrao dos riscos identificados e respectivas respostas so definidos abaixo:
Tabela 16 - Funes e responsabilidades
Coordenador do projeto Campeo
Consultoria
Realizar o levantamento e o acompanhamento dos riscos do projeto; Executar as estratgias definidas na planilha de riscos; Fornecer feedback para a alta gerncia. Apoiar a coordenao do projeto na execuo das suas tarefas; Resolver conflitos; Gerenciar expectativas da presidncia e demais diretorias; Avaliar desempenho das atividades. Direcionar, avaliar e acompanhar atividades da coordenao do projeto e demais membros do worktime;
3. Elaborao do Oramento
Esta seo fornece informaes sobre o oramento para o gerenciamento dos riscos que no est includo na linha de base de custos deste projeto.
4. Cronologia
Esta seo fornece informaes sobre a cronologia dos processos de gerenciamento dos riscos e inclui atividades a eles associadas no cronograma do projeto.
167
5. Categoria de Riscos
Esta seo documenta as categorias de riscos que agregaro os riscos identificados de maneira sistemtica.
Projeto tcnico
Gerenciamento
Organizacionais
Externos
Tecnologia desconhecida
Planejamento do cronograma
Cronogramas do projeto
Riscos legais
Riscos de desempenho
Disciplinas do projeto
Contratos
Tecnologia complexa
Planejamento de recursos
Objetivos no realistas
Hardware
Estimativas de custos
Falta de verba
Oramentos
Problemas pessoais
Planejamento da comunicao
Definio de escopo
Figura 10 - Estrutura Analtica dos Riscos (EAR)
6. Definies de Probabilidade e Impacto dos Riscos

A probabilidade define a chance de um evento ocorrer. Para este projeto definem-se quatro nveis de probabilidade: 0,8 80% de probabilidade que o evento ocorra; 0,6 60% de probabilidade que o evento ocorra; 0,4 40% de probabilidade que o evento ocorra; 0,2 20% de probabilidade que o evento ocorra;
168
O impacto a quantidade de ganhos ou danos que um evento de risco representa para o projeto. Desta forma, a escala de impacto de riscos determinada abaixo com base nos objetivos custos, tempo e qualidade:
Tabela 17 - Escala de impacto dos riscos
Custo Tempo Qualidade
Nenhum impacto significativo Nenhum impacto significativo Nenhum impacto significativo
Aumento inferior a 6% Aumento inferior a 6% Poucos componentes afetados
Aumento de 712% Aumento de 712% Impacto significativo exigindo aprovao do cliente para prosseguir
Aumento de 1318% Aumento de 1318% Qualidade inaceitvel
Aumento superior a 18% Aumento superior a 18% Produto no usvel
7. Matriz de Probabilidade e Impacto

A matriz de probabilidade e impacto define uma pontuao total dos riscos para o projeto. Os riscos que foram identificados e que possuem um alto valor de impacto merecem maior ateno para execuo do plano de resposta. Os valores de impacto definidos na tabela abaixo sero utilizadas durante a anlise dos riscos.
Tabela 18 - Matriz de probabilidade e impacto
Valores de Impacto Probabilidade Muito baixo 0,05 0,04 0,03 0,02 0,01 Baixo 0,2 0,16 0,12 0,08 0,04 Mdio 0,4 0,32 0,24 0,16 0,08 Alto 0,6 0,48 0,36 0,24 0,12 Muito Alto 0,8 0,64 0,48 0,32 0,16
0,8 0,6 0,4 0,2
8. Tolerncia das Partes Interessadas

Esta seo documenta os nveis de tolerncia das partes interessadas aos riscos identificados.
169
APNDICE R PLANILHA DE RISCOS
170
Planilha de Riscos Identificao dos Riscos

Projeto:
Projeto de Implantao do CMMI-DEV L2 Probabilidade de Ocorrncia 0,8
Categoria
Subcategoria Planejamento de recursos
ID
Descrio do Risco Indisponibilidade de pessoal devido a priorizao de outros projetos
Tipo
Gatilho Aumento das solicitaes de manuteno e servio para outros projetos por parte dos clientes Desvio significativo entre o planejado e o realizado Aumento das solicitaes de manuteno e servio para outros projetos Desvio significativo entre o planejado e o realizado Desvio significativo entre o planejado e o realizado Comunicao de alterao dos interesses Comunicao de alterao dos interesses Desvio significativo entre o planejado e o realizado Desvio significativo entre o planejado e o realizado Comunicao de alterao dos interesses Desvio significativo entre o custo planejado e o realizado Desvio significativo entre o planejado e o realizado No homologao do sistema desenvolvido No realizao das atividades
Causas Problemas na execuo dos outros projetos Baixo interesse e comprometimento dos gerentes para a realizao das atividades por descrdito da melhoria. Falta de conhecimento. Priorizao das solicitaes junto aos clientes. Problemas na execuo dos outros projetos Decorrencia de outros riscos Dificuldade na utilizao de novas tecnologias ou readequao de uso das tecnologias j existentes. Mudana de interesse ou foco por parte da presidncia e/ou diretorias Mudana de interesse ou foco por parte da presidncia e/ou diretorias Reunies improdutivas junto a consultoria. Pouca ou nenhuma experincia. Conhecimento mediano da tecnologia Mudana de interesse, redirecionamento da consultoria Acompanhamento deficiente dos projetos, outros riscos executados Pouca ou nenhuma experincia da consultoria No atendimento dos sistemas de apoio aos requisitos Insatisfao, conflito de interesses
Impacto
Grau Risco
Status
Proprietrio
Gerenciamento
RG001
Negativo
Alto
0,48
Risco Inicial
Ana Beatriz
Organizacional
Cronogramas de projeto
RO001 Outros atrasos no cronograma
Negativo
0,8
Alto
0,48
Risco Inicial
Ana Beatriz
Gerenciamento
RG002
Atraso na implantao da infraestrutura necessria
Negativo
0,6
Alto
0,36
Risco Inicial
Ana Beatriz, Waldemar Nogueira Ana Beatriz
Gerenciamento
Planejamento RG005 Aumento dos custos do cronograma Tecnologia desconhecida Definio de escopo RT001 Outros atrasos no cronograma
Negativo
0,6
Alto
0,36
Risco Inicial
Projeto tcnico
Negativo
0,6
Alto
0,36
Risco Inicial
Ana Beatriz
Gerenciamento
RG007 Mudana de foco da empresa
Negativo
0,4
Muito alto
0,32
Risco Inicial
Ana Beatriz
Gerenciamento
Planejamento RG010 Diminuio dos prazos do cronograma Planejamento de recursos RG003 Outros atrasos no cronograma
Negativo
0,4
Muito alto
0,32
Risco Inicial
Ana Beatriz Ana Beatriz, Evandro Tavares Ana Beatriz
Gerenciamento
Negativo
0,6
Mdio
0,24
Risco Inicial
Gerenciamento
Planejamento Atrasos nas entregas dos sistemas de RG004 do cronograma apoio Definio de escopo RG006 Mudanas na especificao dos requisitos
Negativo
0,6
Mdio
0,24
Risco Inicial
Gerenciamento
Negativo
0,4
Alto
0,24
Risco Inicial
Ana Beatriz
Gerenciamento Oramentos
RG008 Estouro do oramento
Negativo
0,4
Alto
0,24
Risco Inicial
Ana Beatriz
Gerenciamento
Planejamento de recursos Riscos de desempenho
RG009 Outros atrasos no cronograma
Negativo
0,4
Alto
0,24
Risco Inicial
Ana Beatriz
Projeto tcnico
RT002 Sistema de apoio de baixa qualidade No aceitao das decises por partes dos gerentes
Negativo
0,4
Alto
0,24
Risco Inicial
Ana Beatriz
Planejamento Gerenciamento da comunicao
RG011
Negativo
0,4
Mdio
0,16
Risco Inicial
Ana Beatriz
171
Gerenciamento
Negativo
Atraso no incio da execuo das atividades Desvio significativo entre o planejado e o realizado Desvio significativo entre o planejado e o realizado No recebimento dos recursos
Atrasos da consultoria, reagendamento de encontros. No entendimento dos requisitos
0,4
Mdio
0,16
Risco Inicial
Ana Beatriz
Gerenciamento
Planejamento Atrasos nas entregas dos sistemas de RG013 do cronograma apoio Planejamento RG014 Atrasos nas entregas dos modelos do cronograma Falta de verba Objetivos no realistas Problemas pessoais Indisponibilidade de recursos de custo RO003 para treinamentos, hospedagens, transporte e alimentao RO002 Atrasos para tomada de decises junto aos gerentes
Negativo
0,4
Mdio
0,16
Risco Inicial
Ana Beatriz
Gerenciamento
Negativo
No entendimento dos requisitos No aceitao de envio de recursos ou atraso para envio Indefinio ou conflito de interesses
0,4
Mdio
0,16
Risco Inicial
Ana Beatriz
Organizacional
Negativo
0,4
Mdio
0,16
Risco Inicial
Ana Beatriz
Organizacional
Negativo
Reunies demoradas Busca por outras oportunidades de emprego Insatisfao dos colaboradores, atraso de pagamento dos servios aos clientes
0,6
Baixo
0,12
Risco Inicial
Ana Beatriz
Organizacional
Negativo
Insatisfao, conflito de interesses
0,2
Alto
0,12
Risco Inicial
Ana Beatriz
Organizacional Total
Falta de verba
Negativo
Atrasos de pagamento
0,4
Muito Baixo
0,02
Risco Inicial
Ana Beatriz 21
Planilha de Riscos Plano de Resposta

Projeto:
Necessita anlise adicional?
Categoria
Subcategoria Planejamento de recursos Cronogramas de projeto Planejamento de recursos
ID
Descrio do Risco Indisponibilidade de pessoal devido a priorizao de outros projetos
Estratgia
Urgncia
Aes necessrias Realizar negociao de recursos junto aos gerentes de unidades Realizar reunio de esclarecimento e motivao. Realizar solicitao de resoluo de conflitos junto ao campeo Realizar negociao de recursos junto aos gerentes de unidades Realizar readequao com foco na diminuio do escopo ou realocao de recursos. Realizao de novos treinamentos. Negociao de prazos ou realizao de horas extras Realizar paralizao do projeto.
Plano de contingncia Realizar contrataes e/ou treinar e capacitar recursos com alta disponibilidade.
Reservas para contingncia 20 dias de esforo adicional para capacitao
Gerenciamento
RG001
Ameaa - Aceitao Ativa
Sim
Sim
Organizacional
Ameaa - Mitigao
Sim
No
Gerenciamento
RG002
Atraso na implantao da infraestrutura necessria
Sim
Sim
Realizar a implantao. Negociar pagamento de horas extras.
Gerenciamento
Planejamento RG005 Aumento dos custos do cronograma Tecnologia desconhecida Definio de escopo RT001 Outros atrasos no cronograma
Ameaa - Mitigao
Sim
Sim
Projeto tcnico
Ameaa - Mitigao
Sim
No
Gerenciamento
RG007 Mudana de foco da empresa
Ameaa - Aceitao Passiva
Sim
No
172
Planejamento Gerenciamento RG010 Diminuio dos prazos do cronograma Planejamento de recursos
Ameaa - Mitigao
Sim
Sim
Realizar readequao com foco na diminuio do escopo ou realocao de recursos. Realizar replanejamento. Renegociar agendamentos. Verificar motivaes da consultoria. Realizao de workshop de atualizao de conhecimento tecnolgico. Disponibilizao de material para aprendizagem. Negociar prazos. Realizar readequao com foco na diminuio do escopo ou realocao de recursos. Diminuio do escopo. Readequao dos prazos e dos recursos alocados. Realizar solicitao de resoluo de conflitos junto ao campeo Solicitar outro consultor. Realizao de reunio para obteno de entendimento dos requisitos Realizar solicitao de resoluo de conflitos junto ao campeo Renegociar agendamentos. Realizao de reunio para obteno de entendimento dos requisitos Realizao de reunio para obteno de entendimento dos requisitos Negociar financiamento e realizar proposta Realizar solicitao de resoluo de conflitos junto ao campeo Se recurso importante para o projeto, negociar junto ao colaborador. Realizar solicitao de apoio para resoluo de conflitos junto ao campeo Realizar solicitao de resoluo de conflitos junto ao campeo Realizar contrataes e/ou treinar e capacitar recursos com alta disponibilidade. Realizar financiamento prprio dos custeios e negociar devoluo a prazo.
Gerenciamento
Ameaa - Mitigao
No
Sim
Gerenciamento
Planejamento Atrasos nas entregas dos sistemas de RG004 do cronograma apoio
Ameaa - Eliminao
No
Sim
Gerenciamento
Definio de escopo
RG006
Mudanas na especificao dos requisitos
Ameaa - Eliminao
No
Sim
Gerenciamento Oramentos
RG008 Estouro do oramento
Ameaa - Mitigao
No
Sim
Gerenciamento
Planejamento de recursos Riscos de desempenho
Ameaa - Eliminao
No
No
Projeto tcnico
RT002 Sistema de apoio de baixa qualidade
Ameaa - Mitigao
No
No
Planejamento Gerenciamento da comunicao Gerenciamento Planejamento de recursos
RG011
No aceitao das decises por partes Ameaa - Transferncia dos gerentes Ameaa - Mitigao
No
Sim
No
Sim
Gerenciamento
Planejamento Atrasos nas entregas dos sistemas de RG013 do cronograma apoio Planejamento RG014 Atrasos nas entregas dos modelos do cronograma Falta de verba Objetivos no realistas
Ameaa - Mitigao
No
Sim
Gerenciamento
Ameaa - Mitigao
No
Sim
Organizacional
Indisponibilidade de recursos de custo RO003 para treinamentos, hospedagens, Ameaa - Aceitao Ativa transporte e alimentao RO002 Atrasos para tomada de decises junto aos gerentes Ameaa - Transferncia
No
Sim
Organizacional
No
Sim
Organizacional
Problemas pessoais
No
Sim
20 dias de esforo adicional para capacitao
Organizacional Total
Falta de verba
Ameaa - Transferncia
No
Sim
173
ANEXO I PROCESSO BSICO DE SOFTWARE UNIDADE TRIBUTRIA
174
175

GP 01

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

GP 01

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE DE TECNOLOGIA DE JOO PESSOA

MAXWELL ANDERSON IELPO DO AMARAL

JOO PESSOA 2010

MAXWELL ANDERSON IELPO DO AMARAL

JOO PESSOA 2010

MAXWELL ANDERSON IELPO DO AMARAL

Aprovada em 28 de maro de 2010.

minha amiga, conselheira e esposa, Lu.

Palavras-chave: planejamento, projeto, processo, CMMI-DEV, PMBOK.

Keywords: planning, design, process, CMMI-DEV, PMBOK.

1. 2. 2.1. 2.2. 2.3. 3. 3.1.

REFERNCIAS .......................................................................................................................... 53 GLOSSRIO ............................................................................................................................... 55

Realizar a anlise e desenvolver o projeto de processos ou de produto.

Figura 2 - Grupo de Processos de Planejamento

Nvel 5 Nvel 4 Nvel 3 Nvel 2 Nvel 1 (caos)

5 4 Capacidade 3 2 1 Processos PP PMC REQM SAM MA

Figura 4 - Representao Contnua

1.3. Processo de Implantao de Kulpa e Johnson

Figura 5 - Processo de Implantao do CMMI-DEV

2.1. Viso geral

2.1.1. Caso de negcio

CMM significa Capability Maturity Model e a antiga denominao dada ao CMMI.

Produtividade (pontos por funo/dia)

2.1.2. Viso da estrutura organizacional da empresa

Gerente da Unidade de Apoio Unidade Oramentria e Administrativa Unidade Recursos Humanos

Demais unidades de apoio

Gerente da Unidade de Apoio

Gerente da Unidade de Apoio

Figura 6 - Estrutura Organizacional da eGovSS

2.2. O processo de trabalho das equipes de desenvolvimento

2.2.1. Anlise quantitativa da carga de trabalho das unidades

Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Mdia

Quantidade LOC 451.623 1.545.253 455.930 696.522 3.149.328

Quantidade EBD 923 2.189 566 1.666 5.344

Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Mdia

Alocao mdia desenvolvimento 70% 57% 63% 79% 67,1%

Unidade Organizacional Administrativo

Recursos Humanos Oramentrio Tributao Totais

309.050 91.050 139.304 765.215

437 113 333 1.344

Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Totais

Registradas 293 725 239 438 1.695

Atendidas 105 675 170 391 1.341

No atendidas 188 50 69 47 354

% concluda 36% 93% 71% 89% 72%

Tabela 6: Solicitaes registradas, atendidas e no atendidas por desenvolvedor.

Unidade Organizacional Administrativo Recursos Humanos Oramentrio Tributao Totais

Solicitaes registradas 146,5 145,0 47,8 87,6 426,9

Solicitaes atendidas 52,5 135,0 34,0 78,2 299,7

Solicitaes no atendidas 94,0 10,0 13,9 9,4 127,3

3. O PROJETO DE IMPLANTAO PARA MELHORIA DE PROCESSOS

4.1 Processos das fases de iniciao e planejamento

Organizao de alguns ativos de processos organizacionais; Registro das partes interessadas.

4.2. Entradas e sadas da iniciao e do planejamento

4.2.1. Termo de abertura do projeto

4.2.2. Declarao de trabalho do projeto

4.2.3. Caso de negcio

4.2.4. Fatores ambientais da empresa

Salrio bruto CLT Jnior

Salrio bruto CLT Pleno

Salrio bruto CLT Snior

Administrador Gerente Contabilista Engenheiro de Software Analista de Suporte

R$ 2.300,00 R$ 1.800,00 R$ 1.800,00 R$ 1.500,00