MPS.

BR - Melhoria de Processo do Software Brasileiro

Guia de Implementao Parte 1: Nvel G

(Verso 1.1)

Este guia contm orientaes para a implementao do nvel G do Modelo de Referncia MR-MPS.

Julho de 2007

Copyright 2007 - SOFTEX Direitos desta edio reservados pela Sociedade SOFTEX A distribuio ilimitada desse documento est sujeita a copyright ISBN (Solicitado Biblioteca Nacional)

Sumrio 1 2 3 4 Prefcio ............................................................................................................... 3 Introduo ........................................................................................................... 4 Objetivo ............................................................................................................... 5 Comeando a implementao do MPS.BR pelo nvel G ..................................... 6

5 Gerncia de Projetos (GPR)................................................................................ 6 5.1 Propsito.......................................................................................................... 6 5.2 Fundamentao terica ................................................................................... 7 5.3 Resultados esperados ..................................................................................... 8 6 Gerncia de Requisitos (GRE) ...........................................................................17 6.1 Propsito.........................................................................................................17 6.2 Fundamentao terica ..................................................................................17 6.3 Resultados esperados ....................................................................................18 7 Os atributos de processo no nvel G ..................................................................20 7.1 AP 1.1 - O processo executado ...................................................................21 7.2 AP 2.1 - O processo gerenciado ..................................................................21 Referncias bibliogrficas..........................................................................................24 Lista de colaboradores do Guia de Implementao Parte 1 verso 1.1 Julho/2007 ..................................................................................................................................25 Lista de colaboradores do Guia de Implementao Parte 1 verso 1.0 Dezembro/2006 .........................................................................................................26

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

2/26

Prefcio

O MPS.BR1 um programa para Melhoria de Processo do Software Brasileiro, est em desenvolvimento desde dezembro de 2003 e coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), contando com apoio do Ministrio da Cincia e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). A coordenao do Programa MPS.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Frum de Credenciamento e Controle (FCC) e a Equipe Tcnica do Modelo (ETM). Atravs destas estruturas, o MPS.BR obtm a participao de representantes de Universidades, Instituies Governamentais, Centros de Pesquisa e de organizaes privadas, os quais contribuem com suas vises complementares que agregam qualidade ao empreendimento. O FCC tem como principais objetivos assegurar que as Instituies Implementadoras (II) e Instituies Avaliadoras (IA) sejam submetidas a um processo adequado de credenciamento e que suas atuaes no se afastem dos limites ticos e de qualidade esperados, alm de avaliar e atuar sobre o controle dos resultados obtidos pelo MPS.BR. Por outro lado, cabe ETM atuar sobre os aspectos tcnicos relacionados ao Modelo de Referncia (MR-MPS) e Mtodo de Avaliao (MA-MPS), tais como a concepo e evoluo do modelo, elaborao e atualizao dos Guias do MPS.BR, preparao de material e definio da forma de treinamento e de aplicao de provas, publicao de relatrios tcnicos e interao com a comunidade visando identificao e aplicao de melhores prticas. A criao e o aprimoramento deste Guia de Implementao so atribuies da ETM, sendo que este guia faz parte do seguinte conjunto de documentos de apoio ao MPS.BR:

Guia Geral [MPS.BR, 2007a]; Guia de Avaliao [MPS.BR, 2007b]; Guia de Aquisio [MPS.BR, 2007c]; e Guia de Implementao (partes 1 a 7).

Este Guia de Implementao fornece orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS, detalhando os processos contemplados nos respectivos nveis de maturidade e os resultados esperados com a implementao dos processos. O Guia de implementao est subdividido em 7 partes, contemplando, respectivamente, os seguintes nveis de maturidade:

Parte 1: nvel G;

MPS.BR, MR-MPS, MA-MPS e MN-MPS so marcas da SOFTEX. 3/26

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

Parte 2: nvel F; Parte 3: nvel E; Parte 4: nvel D; Parte 5: nvel C; Parte 6: nvel B; e Parte 7: nvel A. Introduo

As mudanas que esto ocorrendo nos ambientes de negcios tm motivado as empresas a modificarem estruturas organizacionais e processos produtivos, saindo da viso tradicional baseada em reas funcionais em direo a redes de processos centrados no cliente e com foco nos resultados. A competitividade depende, cada vez mais, do estabelecimento de conexes nestas redes, criando elos essenciais nas cadeias produtivas. Alcanar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e servios correlatos, como dos processos de produo e distribuio de software. Desta forma, assim como para outros setores, qualidade fator crtico de sucesso para a indstria de software. Para que o Brasil tenha um setor de software competitivo, nacional e internacionalmente, essencial que os empreendedores do setor coloquem a eficincia e a eficcia dos seus processos em foco nas empresas, visando oferta de produtos de software e servios correlatos conforme padres internacionais de qualidade. Em 2003, no incio da concepo do MPS.BR, dados da Secretaria de Poltica de Informtica e Tecnologia do Ministrio da Cincia e Tecnologia (MCT/SEITEC), mostravam que apenas 30 empresas no Brasil possuam avaliao SW-CMM2 (Capability Maturity Model): 24 no nvel 2; 5 no nvel 3; 1 no nvel 4; e nenhuma no nvel 5. Observando-se esta pirmide pde-se concluir que a qualidade do processo de software no Brasil podia ser dividida em dois tipos de empresas. No topo da pirmide, normalmente, estavam as empresas exportadoras de software e outras grandes empresas que desejavam atingir nveis mais altos de maturidade (4 ou 5) do CMMI-SE/SW SM por estgio e serem formalmente avaliadas pelo SEI (Software Engineering Institute), em um esforo que pode levar de 4 a 10 anos. Na base da pirmide, em geral, encontrava-se a grande massa de micro, pequenas e mdias empresas de software brasileiras, com poucos recursos e que necessitam obter melhorias significativas nos seus processos de software em 1 ou 2 anos. O foco principal do MPS.BR, embora no exclusivo, est neste segundo grupo de empresas. Busca-se que ele seja adequado ao perfil de empresas com diferentes tamanhos e caractersticas, pblicas e privadas, embora com especial ateno s micro, pequenas e mdias empresas. Tambm espera-se que o MPS.BR seja compatvel com os padres de qualidade aceitos internacionalmente e que tenha

CMM is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. 4/26

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

como pressuposto o aproveitamento de toda a competncia existente nos padres e modelos de melhoria de processo j disponveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princpios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras, estando em consonncia com as principais abordagens internacionais para definio, avaliao e melhoria de processos de software. O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliao e melhoria da qualidade e produtividade de produtos de software e servios correlatos. Dentro desse contexto, o MPS.BR possui trs componentes: Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-MPS) e Modelo de Negcio (MN-MPS). O MPS.BR est descrito por meio de documentos em formato de guias:

Guia Geral: contm a descrio geral do MPS.BR e detalha o Modelo de Referncia (MR-MPS), seus componentes e as definies comuns necessrias para seu entendimento e aplicao. Guia de Aquisio: descreve um processo de aquisio de software e servios correlatos. descrito de forma a apoiar as instituies que queiram adquirir produtos de software e servios correlatos. Guia de Avaliao: descreve o processo e o mtodo de avaliao MA-MPS, os requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA). Guia de Implementao: srie de sete documentos que fornecem orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS. Objetivo

O Guia de Implementao fornece orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS, detalhando os processos contemplados nos respectivos nveis de maturidade e os resultados esperados com a implementao dos processos. Este documento corresponde parte 1 do Guia de Implementao e aborda a implementao do nvel de maturidade G. Este documento destinado, mas no est limitado, a organizaes interessadas em utilizar o MR-MPS para melhoria de seus processos de software e Instituies Implementadoras (II). As alteraes deste Guia de Implementao em relao verso 1.0 so decorrentes de:

mudanas realizadas na verso 1.2 do Guia Geral; melhoria da definio de alguns resultados de processo e resultados de atributos de processo, com o intuito de facilitar o entendimento e a aplicabilidade do MRMPS;
5/26

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

correo ortogrfica e gramatical; alteraes para compatibilidade com o CMMI-DEV verso 1.2; e adequao das referncias bibliogrficas. Comeando a implementao do MPS.BR pelo nvel G

O nvel G o primeiro nvel de maturidade do MR-MPS. Sua implementao deve ser executada com cautela por estabelecer o incio dos trabalhos em implantao de melhoria dos processos de software na organizao. Ao final da implantao deste nvel a organizao deve ser capaz de gerenciar parcialmente seus projetos de desenvolvimento de software. Dois pontos so desafiadores na implantao do nvel G: (1) mudana de cultura organizacional, orientando a definio e melhoria dos processos de desenvolvimento de software; (2) definio do conceito acerca do que projeto para a organizao. Diversas organizaes de software trabalham com evoluo de produtos, e precisam adequar as suas formas de trabalhar para se tornarem organizaes orientadas a projetos. Ser orientada a projetos significa: redefinir algumas operaes (atividades de rotina), j em andamento, como projeto, estabelecendo objetivos, prazos e escopo para sua execuo. A prxima seo descreve em mais detalhes o que deve ser considerado para uma organizao estar orientada a projetos. 5 Gerncia de Projetos (GPR)

5.1 Propsito O propsito do processo Gerncia de Projetos estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o andamento do projeto que permitam a realizao de correes quando houver desvios significativos no desempenho do projeto. O propsito deste processo evolui medida que a organizao cresce em maturidade. Assim, a partir do nvel E, alguns resultados evoluem e outros so incorporados, de forma que a gerncia de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados. No nvel B, a gerncia de projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da organizao. Novamente, alguns resultados evoluem e outros so incorporados. O processo Gerncia de Projetos (GPR) envolve vrias atividades, como: desenvolver um plano geral de controle do projeto; obter o comprometimento e mant-lo ao longo de toda a execuo do projeto; e conhecer o progresso do projeto, de maneira que aes corretivas possam ser tomadas quando a execuo do projeto desviar do planejado. O desenvolvimento do plano do projeto inclui: identificar e estimar o escopo, os produtos de trabalho e as tarefas do projeto; estabelecer recursos necessrios; identificar e analisar riscos do projeto; estabelecer compromissos; e definir cronograma de execuo baseado no ciclo de vida definido para o projeto. O plano
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 6/26

do projeto estabelece a base de execuo e controle para as atividades do projeto junto aos seus interessados (especialmente o cliente). Todos os interessados devem estar comprometidos com ele. O progresso da execuo do projeto determinado pela comparao dos atributos reais de produtos de trabalho e tarefas, esforo, custo e cronograma com o que foi planejado nos marcos ou em pontos de controle predefinidos no planejamento do projeto. A visibilidade apropriada possibilita a tomada de aes corretivas quando o status do projeto se desvia significativamente do esperado. Tais aes podem exigir o replanejamento, para incluir a reviso do plano original, o estabelecimento de novos acordos ou atividades adicionais de mitigao de riscos no plano. Alguns resultados do processo Gerncia de Projetos (GPR) evoluem e outros so adicionados ao processo nos nveis de maturidade E e B do MR-MPS. Esta parte do Guia de Implementao apresenta orientaes apenas para implementar nas organizaes os resultados do processo Gerncia de Projetos (GPR) a partir do nvel de maturidade G do MR-MPS. As orientaes de implementao dos demais resultados esperados desse processo so apresentadas nas partes 3 e 6 do Guia de Implementao. 5.2 Fundamentao terica O PMI (Project Management Institute), um dos mais conceituados e reconhecidos institutos na rea de gerenciamento de projetos, responsvel pela publicao e atualizao do PMBOK (Project Management Body of Knowledge). O PMBOK um guia em gerncia de projetos. Ele agrupa o conhecimento em gerncia de projetos que amplamente reconhecido como as boas prticas deste tipo de gerenciamento. Antes de falar de gerenciamento de projetos, conveniente definir o que um projeto. O PMBOK [PMBOK, 2004] apresenta uma das definies de projeto mais reconhecidas atualmente: Projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. A temporalidade na definio de projeto significa que todos os projetos devem possuir um incio e um fim bem definidos e estabelecidos. O fim do projeto atingido quando os objetivos do projeto tiverem sido alcanados, ou quando se tornar claro que os objetivos no sero ou no podero ser alcanados, ou ainda quando o projeto for cancelado. O termo produto, servio ou resultado exclusivo so as entregas exclusivas de um projeto. A exclusividade uma caracterstica importante a ser observada nas entregas do projeto. Outra caracterstica importante de projeto a elaborao progressiva que integra os conceitos de temporalidade e exclusividade. Elaborao progressiva significa desenvolver em etapas e por incrementos. Por exemplo, o escopo do projeto ser identificado de maneira geral no incio do projeto e se tornar mais claro e refinado a medida que a equipe do projeto desenvolve um entendimento mais completo dos objetivos e das entregas. Outro conceito importante a ser destacado so as operaes. Assim como os projetos, as operaes constituem a execuo de um trabalho para atingir um conjunto de objetivos, compartilhando algumas caractersticas como: so planejadas, executadas e controladas por pessoas e tm restries de recursos. As operaes e os projetos diferem principalmente no que diz respeito temporalidade,
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 7/26

pois as operaes so contnuas e repetitivas, enquanto os projetos so temporrios e exclusivos. Embora exista essa pequena diferena conceitual entre projeto e operao, muitas operaes so redefinidas e gerenciadas como projeto, prtica comumente chamada de Gerenciamento por Projetos. Uma organizao que adota essa abordagem deve definir atividades de acordo com a definio de projeto apresentada anteriormente. Contudo, isso no significa que todas as operaes podem ou devem ser tratadas como projeto. A adoo da abordagem de Gerenciamento por Projeto envolve tambm a adoo de uma cultura organizacional semelhante cultura de gerenciamento de projeto. O gerenciamento de projeto na viso do PMBOK (Project Management Body of Knowledge) [PMBOK, 2004] a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto, a fim de atender aos seus requisitos. Gerenciar projeto envolve identificar as necessidades, estabelecer objetivos claros e viveis e balancear as demandas conflitantes em termos de qualidade, escopo, tempo e custo. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e produzir um produto e/ou servio, de acordo com seus requisitos. O IEEE (Institute of Electrical and Electronics Engineers), em seu Glossrio Padro de Terminologias da Engenharia de Software [IEEE Std 610.12, 1990], diz que a gerncia de projetos de software pode ser definida como a aplicao de planejamento, coordenao, medio, monitoramento, controle e divulgao de relatrios, com o intuito de garantir que o desenvolvimento e a manuteno de software sejam sistemticos, disciplinados e qualificados. E, segundo a norma internacional ISO/IEC 12207, o propsito da gerncia de projetos identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou servio, no contexto dos requisitos e restries do projeto [ISO/IEC 12207:1995/Amd 1:2002]. Vale ressaltar que a gerncia de esforo, custos, cronograma, equipe, riscos e de outros fatores est intimamente relacionada a tarefas do processo definido do projeto, o qual pode, tambm, fazer parte do plano do projeto. Certas atividades sero, em nveis mais altos de maturidade, cobertas em outros planos que afetam o projeto, como plano de garantia da qualidade, plano de gerncia de riscos, plano de gerncia de configurao, plano de verificao e plano de validao. No contexto da gerncia do projeto, integrao inclui caractersticas como unificao, consolidao, articulao e aes de integrao que so cruciais para concluir o projeto, atender satisfatoriamente os requisitos dos interessados e clientes, e gerenciar as expectativas [PMBOK, 2004]. 5.3 Resultados esperados 5.3.1 GPR1 - O escopo do trabalho para o projeto definido O escopo do projeto define todo o trabalho necessrio, e somente ele, para entregar um produto e/ou servio que satisfaa as necessidades, caractersticas e funes especificadas para o projeto, de forma a conclu-lo com sucesso.
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 8/26

O escopo o ponto de partida para o planejamento do projeto. A definio do escopo deve estabelecer o que est e o que no est includo no projeto. Para isso, deve-se definir o objetivo e motivao, os limites e restries, todos os produtos que sero entregues e os outros produtos gerados pelo projeto. O escopo pode ser representado por meio de uma Estrutura Analtica do Projeto (EAP) tambm conhecida como WBS (Work Breakdown Structure). A EAP fornece um esquema para identificao e organizao das unidades lgicas de trabalho a serem gerenciadas, que so chamadas de pacotes de trabalho (work packages). Este resultado tambm pode ser implementado por meio de um Documento de Viso ou outro documento que defina, claramente, o escopo do trabalho. 5.3.2 GPR2 - As tarefas e os produtos de trabalho do projeto so dimensionados utilizando mtodos apropriados O escopo do projeto, identificado na forma dos seus principais produtos de trabalho e das tarefas do projeto, deve agora ser decomposto em componentes menores, mais facilmente gerenciveis e possveis de serem dimensionados. Uma estrutura de decomposio do trabalho apropriada deve ser estabelecida. Esta estrutura de decomposio pode ser a EAP do projeto ou estrutura equivalente. A estrutura de decomposio fornece uma referncia para a atribuio de tamanho, esforo, cronograma e responsabilidades, e utilizada como uma estrutura subjacente para planejar, organizar e controlar o trabalho executado no projeto. O tamanho a principal entrada de muitos modelos utilizados para estimar o esforo, custo e cronograma. Este resultado diz respeito estimativa de tamanho, enquanto o GPR4 refere-se estimativa de esforo e custo. O tamanho a dimenso das funcionalidades sob o ponto de vista do usurio. So contadas tabelas internas e externas ao sistema, classes, objetos, relatrios, telas, consultas a banco de dados, clculos, transaes e atores dos casos de uso, linhas de cdigo, etc. Uma tcnica bastante utilizada para medir o tamanho do software a tcnica de Anlise de Pontos por Funo (APF) [VAZQUEZ et al., 2005], que visa estabelecer uma medida de tamanho do software em Pontos por Funo. No entanto, importante enfatizar que o uso de uma tcnica deste tipo no exigido no nvel G do MPS.BR. Neste nvel, a estimativa de escopo, produtos e tarefas pode ser feita baseada na complexidade, no nmero de requisitos ou no uso da EAP juntamente com dados histricos e a experincia em projetos anteriores. 5.3.3 GPR3 - O modelo e as fases do ciclo de vida do projeto so definidas O ciclo de vida do projeto consiste de fases e atividades que devem ser definidas de acordo com o escopo dos requisitos, as estimativas para os recursos e a natureza do projeto, visando oferecer maior controle gerencial. O ciclo de vida de projeto define um conjunto de fases, em que cada fase gera produtos de trabalho necessrios para o desenvolvimento de fases posteriores. Essa organizao em fases permite planejar o projeto, incluindo marcos importantes para o controle e revises.

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

9/26

As fases do ciclo de vida representam, de forma abstrata, o esqueleto do processo, que pode ser chamado de modelo de ciclo de vida. De maneira geral, este modelo descreve a estrutura de organizao de atividades do processo em fases e define como essas fases esto relacionadas. Entretanto, ele no descreve um curso de aes precisas, recursos, procedimentos e restries. A escolha de um modelo fortemente dependente das caractersticas do projeto. Assim, importante conhecer alguns modelos de ciclo de vida e em que situaes so aplicveis. Os principais modelos de ciclo de vida podem ser agrupados em trs categorias principais: modelos seqenciais ou cascata, modelos incrementais e modelos evolutivos [ISO/IEC 15271:1998]. Cada um destes modelos pode ser utilizado na sua forma original ou eles podem ser combinados para criar outro modelo de ciclo de vida hbrido. Na norma ISO/IEC 15271 a aplicao de cada modelo de ciclo de vida detalhada. O ciclo de vida dos projetos pode estar predefinido no mbito organizacional, ou seja, a organizao pode preestabelecer que todos os projetos tenham o mesmo ciclo de vida. Pode-se, ainda, predefinir mais de um modelo de ciclo de vida de desenvolvimento de software para a organizao. Neste caso, para cada projeto, ser selecionado aquele que melhor atender s suas caractersticas. A determinao das fases do ciclo de vida do projeto possibilita perodos planejados de avaliao e de tomada de decises, nos quais compromissos significativos so realizados com relao aos recursos, abordagem tcnica, reavaliao de escopo e custo do projeto. 5.3.4 GPR4 - (At o nvel F) O esforo e o custo para a execuo das tarefas e dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas As estimativas de esforo e custo so, normalmente, baseadas nos resultados de anlises utilizando modelos e/ou dados histricos aplicados ao tamanho, atividades e outros parmetros de planejamento. importante destacar que dados histricos incluem os dados de custo, esforo e tempo de projetos executados anteriormente, alm de dados apropriados de escala para equilibrar as diferenas de tamanho e complexidade. As estimativas de esforo e custo tipicamente consideram: o escopo, produtos de trabalho e as tarefas estimadas para o projeto; os riscos; as mudanas j previstas; o ciclo de vida escolhido para o projeto; viagens previstas; nvel de competncia da equipe do projeto, dentre outros. Normalmente as estimativas do escopo, produtos de trabalho e as tarefas estimadas para o projeto so afetadas pelos parmetros de produtividade, resultando nas estimativas de esforo e custo. Os parmetros de produtividade so baseados em dados histricos e devem ser periodicamente calibrados. Os parmetros de produtividade podem ter valores diversos, conforme fatores como experincia do profissional, grau de ineditismo do servio para a organizao ou para os profissionais alocados.

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

10/26

5.3.5 GPR5 - O oramento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, so estabelecidos e mantidos As dependncias entre tarefas so estabelecidas e potenciais gargalos so identificados utilizando mtodos apropriados (por exemplo, anlise de caminho crtico). Os gargalos so resolvidos quando possvel, e o cronograma das atividades com incio, durao e trmino estabelecido. Recursos requeridos so refletidos nos custos estimados. Com base na EAP e nas estimativas de esforo e custo (GPR4), deve ser definido o cronograma, considerando as dependncias entre as tarefas e os marcos e/ou pontos de controle eventos que so considerados significativos no mbito do projeto. importante ter-se o cuidado de manter a coerncia entre ciclo de vida, EAP, estimativas e cronogramas. Com base no cronograma e na estimativa de custos, estabelecido o oramento do projeto. Este resultado importante porque o cronograma e o oramento so instrumentos fundamentais para o acompanhamento do dia-a-dia do projeto. Desta forma, sempre que necessrio, devem ser revistos e atualizados. 5.3.6 GPR6 - Os riscos do projeto so identificados e o seu impacto, probabilidade de ocorrncia e prioridade de tratamento so determinados e documentados Projetos normalmente tm riscos e estes precisam ser identificados, analisados e priorizados. Para facilitar a identificao dos riscos, interessante elaborar uma lista de riscos mais comuns, que deve ser examinada pelo gerente do projeto e/ou equipe do projeto para identificar quais destes so potenciais riscos para o projeto em questo. A anlise da probabilidade de ocorrncia e da gravidade dos problemas decorrentes de sua ocorrncia ajuda a definir a prioridade dos riscos. Os riscos identificados devem ser registrados, bem como o acompanhamento dos seus estados e aes tomadas. Este resultado no significa o Gerenciamento de Riscos, ou seja, a identificao, o gerenciamento e a reduo contnua dos riscos nos nveis organizacionais e de projeto, que so tratados pelo processo Gerncia de Riscos (GRI). Uma planilha de riscos, contendo dados como identificador, descrio, probabilidade, impacto e prioridades no seu tratamento, pode ser utilizada. importante demonstrar que esta planilha est sendo monitorada e atualizada. No nvel G, os riscos so acompanhados para verificar como afetam o projeto e para se tomar medidas, mesmo que ainda sem um gerenciamento completo. 5.3.7 GPR7 - Os recursos humanos para o projeto so planejados considerando o perfil e o conhecimento necessrios para execut-lo O planejamento de recursos humanos determina funes, responsabilidades e relaes hierrquicas do projeto. As funes do projeto podem ser designadas para pessoas ou grupos, os quais podem ser internos ou externos organizao. O planejamento de recursos humanos inclui informaes de como e quando o recurso ser envolvido no projeto, critrios para sua liberao, competncia necessria para a execuo das atividades, mapa de competncias da equipe e identificao de
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 11/26

necessidades de treinamento. A existncia de registros das necessidades e disponibilidade evita a alocao com base em critrios subjetivos. O treinamento inclui todas as atividades realizadas para aprimorar as competncias dos membros da equipe do projeto. O treinamento pode ser formal ou informal. Exemplos de mtodos para realizao de treinamentos incluem treinamento em sala de aula, on-line, baseado em computador, no trabalho, leituras, aconselhamento e orientaes. 5.3.8 GPR8 - As tarefas, os recursos e o ambiente de trabalho necessrios para executar o projeto so planejados Com base na EAP (ou estrutura equivalente), devem ser especificadas as tarefas e previstos os recursos e o ambiente necessrios, incluindo, por exemplo, equipamentos, ferramentas, servios, componentes, viagens e requisitos de processo (processos especiais para o projeto). Os recursos humanos, incluindo treinamentos, so tratados pelo GPR7. Todos os recursos precisam ser explicitamente planejados, mesmo os j considerados como existentes e disponveis ou que sero compartilhados com outros projetos, uma vez que se trata da sua alocao para uso. Estes itens podem, por exemplo, estar registrados no plano do projeto. Caso no haja necessidade de nenhum recurso especial, a ser adquirido especialmente para o projeto, deve-se registrar o fato de que a questo foi examinada. Este resultado importante porque recursos especiais precisam de oramento e planejamento de sua aquisio, o que pode se tornar crtico em alguns projetos. 5.3.9 GPR9 - Os dados relevantes do projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio. Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade e segurana Os dados do projeto so as vrias formas de documentao exigidas para sua execuo, por exemplo: relatrios; dados informais; estudos e anlises; atas de reunies; documentao; lies aprendidas; artefatos gerados; itens de ao; e indicadores. Os dados podem estar em qualquer formato e existir em qualquer meio, como: impressos ou desenhados em diversos materiais; fotografias; meio eletrnico; e multimdia. Alguns dados podem ser disponibilizados aos clientes, enquanto outros no, necessariamente, o sero. A distribuio pode ocorrer de vrias formas, incluindo a transmisso eletrnica. A identificao, coleta, armazenamento, distribuio (incluindo regras de segurana e confidencialidade) para garantir a integridade, acesso e segurana aos dados devem ser planejados. O motivo de se coletar cada dado tambm dever ser evidenciado. importante identificar os dados relevantes do projeto, para depois colet-los, armazen-los e distribu-los de forma controlada, lembrando que isso implica em custo. Desta forma, os dados devem ser coletados somente quando forem necessrios. A questo da confidencialidade, mesmo quando no declarada pelo cliente, deve ser tratada com extremo cuidado. A inexistncia de dados confidenciais deve ser explicitada.
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 12/26

Se a organizao tem um critrio padro para execuo dessas atividades, isto deve ser registrado no plano do projeto ou em outro documento. 5.3.10 GPR10 - (At o nvel F) Planos para a execuo do projeto so estabelecidos e reunidos no Plano do Projeto Todas as informaes definidas e coletadas para o projeto relacionadas a escopo, ciclo de vida, viabilidade, tamanho / esforo / custo das tarefas a serem realizadas e produtos de trabalho a serem gerados, oramento, cronograma, riscos, provimento de recursos, ambiente de trabalho, alocao e treinamento de pessoas, envolvimento das partes interessadas, gerao / coleta / armazenamento / controle de dados e documentos devem ser organizadas de forma a possibilitar um gerenciamento adequado do projeto. Estas informaes geralmente esto contidas em um ou mais documentos (planos), que devem estar relacionados entre si de alguma forma, compondo o planejamento geral do projeto. A reunio destes documentos entendida como sendo o Plano de Projeto. As tarefas do processo definido para o projeto podem, tambm, fazer parte deste Plano do Projeto. Vale aqui destacar a importncia de existir um alinhamento entre o que foi estimado, o que est sendo planejado e o que ser acompanhado. A utilizao de uma mesma referncia propicia uma maior visibilidade ao projeto, facilitando em muito no s o seu gerenciamento, mas tambm a formao de uma base histrica, que poder beneficiar a organizao em etapas posteriores de melhoria. O monitoramento efetivo do projeto depender de uma organizao adequada destas informaes de planejamento: ao longo do projeto, elas devero ser comparadas aos dados obtidos durante sua execuo, em busca de uma maior visibilidade do andamento do projeto. Quando necessrio, o planejamento dever ser revisto. Em nveis mais altos de maturidade, certas atividades sero cobertas por outros planos que tambm afetam o projeto, como plano de garantia da qualidade, plano de gerncia de configurao, plano de gerncia de riscos, plano de verificao e plano de validao. Neste contexto, para uma monitorao efetiva do projeto, ser necessrio integrar todos estes planos. 5.3.11 GPR11 - A viabilidade de atingir as metas do projeto, considerando as restries e os recursos disponveis, avaliada. Se necessrio, ajustes so realizados O estudo de viabilidade considera o escopo do projeto e examina aspectos tcnicos (requisitos e recursos), financeiros (capacidade da organizao) e humanos (disponibilidade de pessoas com a capacitao necessria). Deve-se considerar tambm os objetivos de negcio da organizao. Muitas vezes prefervel no iniciar ou parar um projeto j iniciado do que prosseguir com um projeto invivel. O prosseguimento pode levar a perdas maiores, tanto para o fornecedor como para o cliente. No incio do projeto, uma avaliao preliminar deve ser conduzida, a partir da viso geral dos objetivos e caractersticas dos resultados pretendidos, dos recursos financeiros, tcnicos, humanos, bem como restries impostas pelo cliente,
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 13/26

ambiente externo e interno, e condies de desenvolvimento. medida que o projeto evolui, a viabilidade de sucesso pode ser reavaliada com mais preciso. As mudanas de requisitos so eventos que impem a realizao de uma reavaliao da viabilidade do projeto. Em marcos do projeto e mesmo durante as atividades de acompanhamento, pode ser necessria a confirmao da viabilidade de continuidade do projeto. Devem ser estabelecidos critrios para realizao da anlise de viabilidade. Em projetos rotineiros, estudos de viabilidade podem no ser necessrios. Se este for o caso, deve-se definir um critrio explcito para no realizar a anlise de viabilidade. 5.3.12 GPR12 - O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido Para obter compromissos dos interessados relevantes, importante revisar o planejamento com eles e conciliar as diferenas existentes entre os recursos estimados e disponveis. Negociaes devem ser realizadas quando existem conflitos entre as diversas variveis do projeto, como: requisitos; custos; prazos. Por exemplo: o escopo pode sofrer reduo para que as metas de prazos e custos sejam cumpridas ou, ao contrrio, aumenta-se o oramento do projeto para que os requisitos sejam atendidos na ntegra, dentro da meta de prazo. Obter o compromisso pode envolver a interao entre todos os interessados relevantes internos e externos ao projeto. Os indivduos ou grupos que se comprometem devero ter a confiana de que o trabalho pode ser executado dentro das restries de custo, cronograma e desempenho. Algumas organizaes costumam realizar uma reunio de incio do projeto (kick off) que pode ser utilizada para resolver os conflitos e obter o comprometimento. O atendimento deste resultado esperado est de certa forma associado ao GPR11, pois a realizao da anlise de viabilidade pode resultar em aes para soluo de conflitos. O planejamento global dos recursos da organizao tambm contribui para a resoluo prvia de conflitos. A soluo dos conflitos e estabelecimento de compromissos fundamental para que o projeto possa efetivamente contar com os recursos planejados, para atingir as metas definidas. 5.3.13 GPR13 - (At o nvel F) O progresso do projeto monitorado com relao ao estabelecido no Plano do Projeto e os resultados so documentados A aderncia aos diversos planos deve ser avaliada continuamente, durante todo o ciclo de vida do projeto. Os resultados e os critrios de concluso de cada tarefa so analisados, as entregas so avaliadas em relao s suas caractersticas (por meio de revises e auditorias, por exemplo), a aderncia ao cronograma e o dispndio de esforos so examinados, bem como o uso dos recursos. Anlises devem ser realizadas e decises serem tomadas considerando-se as variaes dos dados e desvios entre resultados e valores atuais e esperados. O registro e anlise dos
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 14/26

problemas esto relacionados ao GPR16 e o acompanhamento das aes corretivas ao GPR17. O acompanhamento pode ser realizado utilizando-se ferramentas de planejamento, em que se pode examinar o previsto contra o realizado, usando-se indicadores de progresso e cumprimento de marcos, entre outros. O acompanhamento tambm pode ser feito por meio de reunies e comunicao pessoal. Contudo, importante ressaltar que devem existir registros desses acompanhamentos. Esta uma atividade essencial de gerenciamento: acompanhar o que foi planejado, detectar problemas e corrigi-los. 5.3.14 GPR14 - O envolvimento das partes interessadas no projeto gerenciado Devem ser identificados os interessados relevantes no projeto, em que fases eles so importantes e como eles sero envolvidos (comunicaes, revises em marcos de projeto, comprometimentos, entre outros). Uma vez identificado e planejado o envolvimento, este dever ser seguido. Os interessados no projeto podem incluir o cliente e o usurio (ou seus representantes), a direo da organizao e os membros da equipe do projeto. Em projetos pequenos, estas atividades podem ser simplificadas devido ao pequeno nmero de interessados e pouca comunicao necessria em funo do curto prazo. A comunicao envolve questes relativas a prazos, custos, recursos, comprometimentos e tambm requisitos, pois estes afetam as outras variveis. Um plano de gerenciamento das comunicaes, conforme apresentado no PMBOK [PMBOK, 2004], pode cobrir este resultado esperado. Este resultado tem relao com GRE1, em funo da comunicao necessria para o entendimento dos requisitos junto aos seus fornecedores. No processo Gerncia de Projetos, o foco mais amplo e envolve outros aspectos. Este resultado importante porque o distanciamento da gerncia do projeto em relao aos interessados pode acarretar desvios em relao s reais necessidades que o projeto dever atender. Alm da comunicao em si, necessrio verificar se os compromissos assumidos pelas partes interessadas esto sendo cumpridos ou negociados, sejam eles internos ou externos, visando identificar aqueles que no foram satisfeitos ou que possuem um grande risco de no serem satisfeitos. 5.3.15 GPR15 - Revises so realizadas em marcos do projeto e conforme estabelecido no planejamento Revises em marcos do projeto no devem ser confundidas com o acompanhamento descrito em GPR13, que o acompanhamento do dia-a-dia do projeto. Os marcos do projeto precisam, portanto, ser previamente definidos ao se realizar o planejamento do projeto. Podem ser, por exemplo, o incio ou o final de cada fase do projeto ou algumas atividades de fundamental importncia para o seu sucesso. A reviso de incio de fase de projeto tem por objetivo verificar se as
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 15/26

condies para que uma fase seja iniciada esto atendidas. Pode ser que, mesmo que a fase anterior no esteja encerrada, seja possvel iniciar a nova fase, nas condies atendidas e com prazos para o cumprimento de algumas outras condies. A reviso de fim de fase de projeto tem por objetivo verificar se todos os critrios de encerramento de fase foram cumpridos. As revises em marcos podem ter um carter formal, com participao de gerncias superiores, representantes do cliente e outras partes interessadas no projeto. Sempre que necessrio, deve-se realizar um replanejamento e uma nova anlise de sua viabilidade. Este resultado importante porque as revises em marcos so oportunidades para verificar, de forma ampla, o andamento de todo o projeto, independente do acompanhamento do dia-a-dia. Em projetos grandes essas revises so fundamentais, questionando, inclusive, a viabilidade de continuidade do projeto. Alm das revises em marcos, outras revises podero ser estabelecidas no planejamento do projeto. Caso isto ocorra, estas revises devero ser executadas conforme planejado. 5.3.16 GPR16 - Registros de problemas identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas, so estabelecidos e tratados com as partes interessadas As atividades de reviso em marcos (GPR15) e de monitoramento (GPR13) do projeto possibilitam a identificao de problemas que estejam ocorrendo nos projetos. Estes problemas devem ser analisados e registrados, por exemplo, por meio de ferramentas especficas, planilhas ou outros tipos de mecanismos de gerenciamento de problemas. Para completar o trabalho de monitoramento do projeto, os problemas precisam ser corrigidos e gerenciados at a sua resoluo, com base em planos de aes, estabelecidos especificamente para resolver os problemas levantados e registrados (GPR17). 5.3.17 GPR17 - Aes para corrigir desvios em relao ao planejado e para prevenir a repetio dos problemas identificados so estabelecidas, implementadas e acompanhadas at a sua concluso Como resultado do acompanhamento do projeto (GPR13) e das revises em marcos (GPR15), problemas so identificados, analisados e registrados (GPR16). Aes corretivas devem ser estabelecidas para resolver problemas que possam impedir o projeto de atingir seus objetivos se no forem resolvidos de forma adequada. As aes corretivas definidas devem ser gerenciadas at serem concludas. Para isto, pode-se utilizar uma ferramenta especfica de gerenciamento de problemas, como ferramentas de bugtracking. O controle dos problemas levantados, as aes tomadas, os responsveis pelas aes e os resultados devem ser registrados. Os problemas identificados provem a base para a tomada de aes corretivas. Quando apropriado, e quando o impacto e os riscos associados so modelados e gerenciados, as mudanas podem ser realizadas no projeto. Estas mudanas podem tomar a forma de aes corretivas, podem envolver a incorporao de contingncias para que ocorrncias similares sejam evitadas e/ou encadear a
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 16/26

reviso de vrios planos e documentos relacionados para acomodar os problemas inesperados e suas implicaes. Acompanhar o andamento de uma ao corretiva at sua concluso inclui verificar, com uma certa freqncia, se ela j foi resolvida, atuar em possveis pendncias, bem como investigar sua efetividade. Caso no se consiga resolver neste nvel, deve-se escalonar a resoluo das aes a nveis superiores de gerncia. As aes corretivas estabelecidas podem ser reportadas para a gerncia de alto nvel da organizao e para os interessados relevantes, como clientes e usurios. 6 Gerncia de Requisitos (GRE)

6.1 Propsito O propsito do processo Gerncia de Requisitos gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. O principal objetivo da Gerncia de Requisitos controlar a evoluo dos requisitos. O processo Gerncia de Requisitos (GRE) gerencia todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos funcionais e no-funcionais, bem como os requisitos impostos ao projeto pela organizao. Para assegurar que o conjunto de requisitos acordados gerenciado e fornece suporte s necessidades de planejamento e execuo do projeto, a organizao deve executar um conjunto de passos definidos e apropriados. Quando um projeto recebe requisitos de um fornecedor de requisitos pessoa autorizada a participar de sua definio e a solicitar modificao , estes devem ser revisados para resolver questes e prevenir o mau entendimento, antes que os requisitos sejam incorporados ao escopo do projeto. Quando o fornecedor de requisitos e a organizao chegam a um acordo, obtido um compromisso das demais partes interessadas sobre os requisitos. Outras atribuies do processo Gerncia de Requisitos so documentar as mudanas nos requisitos e suas justificativas, bem como manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho em geral e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. 6.2 Fundamentao terica Segundo Dorfmann e Thayer [1990] requisito de software representa a capacidade que deve ser encontrada ou possuda por um determinado produto ou componente de produto para satisfazer a um contrato, a um padro, a uma especificao ou a outros documentos formalmente impostos. Os requisitos indicam a capacidade do software requerida pelo usurio para resolver um problema ou alcanar um objetivo. A gerncia de requisitos envolve estabelecer e manter um acordo entre o cliente e a equipe de projeto sobre os requisitos estabelecidos e sobre qualquer mudana ocorrida neles. Para apoiar esse processo de mudana, fundamental definir e manter a rastreabilidade dos requisitos. Rastreabilidade o grau em que o
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 17/26

relacionamento pode ser estabelecido entre dois ou mais produtos de desenvolvimento de software, especialmente produtos que tenham uma relao de predecessor-sucessor ou de mestre-subordinado com outro; por exemplo, o grau em que requisitos e projeto (design) de um determinado componente de software combinam [IEEE Std 610.12, 1990]. A gerncia de requisitos implementada com a identificao, controle e rastreamento dos requisitos, bem como com o tratamento das mudanas nos requisitos. importante manter a rastreabilidade bidirecional dos requisitos para cada nvel de decomposio do produto. Quando os requisitos so bem gerenciados, a rastreabilidade pode ser estabelecida, desde um requisito fonte at seus requisitos de mais baixo nvel e destes at o seu requisito fonte. Tal rastreabilidade bidirecional auxilia a determinar se todos os requisitos fonte foram completamente tratados e se todos os requisitos de mais baixo nvel podem ser rastreados para uma fonte vlida [CMU/SEI, 2006]. 6.3 Resultados esperados 6.3.1 GRE1 - O entendimento dos requisitos obtido junto aos fornecedores de requisitos O bom entendimento dos requisitos do projeto um dos fatores determinantes para o seu sucesso. O objetivo deste resultado garantir que os requisitos estejam claramente definidos. Este resultado no requer que uma elicitao de requisitos junto aos fornecedores seja realizada. Dado um conjunto de requisitos especificados, necessrio rever com o cliente se as necessidades e expectativas esto sendo atendidas com os requisitos propostos. Como comprovao deste entendimento, deve-se ter um documento de requisitos, que pode ter diferentes formas de acordo com as necessidades da organizao. Uma boa comunicao com os fornecedores de requisitos fundamental para assegurar um bom entendimento das necessidades do cliente e dos requisitos do projeto. Existem diversos assuntos ligados a requisitos que devem ser tratados exclusivamente com os fornecedores de requisitos, como por exemplo: definio de requisitos, aprovao de requisitos, solicitao de mudana nos requisitos, dentre outros. importante destacar que: os fornecedores de requisitos devem ser identificados a partir de critrios predefinidos; o entendimento dos requisitos deve ser sempre obtido junto a estes fornecedores de requisitos; as comunicaes devem ser registradas formalmente em atas, e-mails, ferramentas de comunicao ou outros meios, sendo necessria uma comprovao de que os interessados esto de acordo com o contedo registrado. desejvel que os fornecedores de requisitos estejam identificados e aprovados pelo patrocinador do projeto. Uma possvel opo registrar no plano do projeto quem sero os fornecedores de requisitos e como ser a comunicao com eles, incluindo a definio de como mudanas nos requisitos podero ser solicitadas. Deve ser observado que, caso haja mudanas relacionadas ao que foi estabelecido no plano do projeto, estas mudanas devem ser registradas e aprovadas.

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

18/26

6.3.2 GRE2 - Os requisitos de software so aprovados utilizando critrios objetivos Os requisitos de software estabelecidos devem ser aprovados pelas partes interessadas, aps uma avaliao destes requisitos com base em um conjunto de critrios objetivos, previamente estabelecidos. Alguns exemplos de critrios so: possuir identificao nica; estar claro e apropriadamente declarado; ser relevante; ser completo; estar consistente com os demais requisitos; ser implementvel, testvel e rastrevel. O uso de um checklist para apoiar esta atividade bastante til. Este checklist tambm possibilita que a organizao possa compreender melhor quais os problemas que tm ocorrido em relao especificao de requisitos. A aprovao dos requisitos deve envolver a equipe tcnica da organizao e o cliente, podendo ser realizada de diversas formas. Uma prtica que algumas organizaes tm realizado com o intuito de satisfazer este resultado a realizao de uma reunio de kick off onde se apresenta o projeto como um todo (incluindo seus requisitos). Esta reunio possibilita que as diversas partes possam opinar, aprovar e se comprometer em relao aos requisitos do projeto. Em alguns casos, feita posteriormente. Mudanas nos requisitos podem impactar significativamente o projeto em termos de escopo e estimativas de cronograma e esforo. Portanto, sempre que forem aprovadas mudanas nos requisitos, deve-se obter novas aprovaes dos requisitos do projeto a partir de critrios estabelecidos. 6.3.3 GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida Um mecanismo que permita rastrear a dependncia entre os requisitos e os produtos de trabalho deve ser estabelecido, a fim de facilitar a avaliao do impacto das mudanas de requisitos que possam ocorrer, por exemplo, nas estimativas do escopo, nos produtos de trabalho ou nas tarefas do projeto. A rastreabilidade bidirecional deve acontecer tanto de forma horizontal quanto vertical. A rastreabilidade horizontal estabelece a dependncia entre os requisitos ou produtos de trabalho em um mesmo nvel, por exemplo, rastreabilidade dos requisitos entre si ou rastreabilidade entre cdigos de unidades dependentes. A rastreabilidade vertical estabelece uma rastreabilidade bidirecional desde um requisito fonte, passando pelos seus requisitos de mais baixo nvel, at o nvel de decomposio mais baixo do produto, por exemplo, cdigos de unidade ou mdulos do software. Esse mecanismo deve permitir tambm rastrear itens do nvel mais baixo de decomposio do produto at o(s) seu(s) requisito(s) fonte. A rastreabilidade vertical auxilia a determinar se todos os requisitos fonte foram completamente tratados e se todos os requisitos de mais baixo nvel ou cdigos de unidade podem ser rastreados para um requisito fonte vlido. A rastreabilidade vertical bidirecional possibilita, ento, rastrear requisitos e produtos de trabalho a cdigos de unidade ou mdulos do software implementados. Esse mecanismo de rastreabilidade vertical essencial para a realizao da anlise de impacto de mudanas de requisitos, por exemplo, para identificar de que forma uma mudana de requisito impacta nos planos do projeto que contm as estimativas aprovadas de
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 19/26

esforo e custo para os produtos de trabalho e tarefas, bem como os cdigos de unidade ou mdulos do software que necessitam ser modificados. Por essas anlises, o responsvel pela gerncia do projeto capaz de negociar com o cliente alteraes nos planos do projeto para atender s solicitaes de mudanas de requisitos e, ao mesmo tempo, minimizar os riscos do projeto, como por exemplo, desvios de cronograma e de custos. importante ressaltar que este resultado estabelece a criao de um sistema de rastreamento e que no necessariamente envolve a criao de uma matriz especfica para atendimento ao resultado esperado. Contudo, deve existir um mecanismo que possibilite a realizao da rastreabilidade bidirecional entre os requisitos e os demais produtos de trabalho. 6.3.4 GRE4 - Revises em planos e produtos de trabalho do projeto so realizadas visando identificar e corrigir inconsistncias em relao aos requisitos A consistncia entre os requisitos e os produtos de trabalho do projeto deve ser avaliada e os problemas identificados devem ser corrigidos. Este resultado sugere, portanto, a realizao de revises ou de algum mecanismo semelhante para identificar inconsistncias entre os requisitos e os demais elementos do projeto como, por exemplo, planos, atividades e produtos de trabalho. As inconsistncias identificadas devem ser registradas e aes corretivas executadas a fim de resolv-las. Quando h mudanas nos requisitos, uma vez identificados os impactos da mudana com a utilizao do instrumento de rastreabilidade dos requisitos, importante examinar se os demais artefatos esto consistentes com as alteraes realizadas como, por exemplo: verificar se a planilha de estimativas est contemplando todos os requisitos e mudanas; verificar se as mudanas dos requisitos foram incorporadas ao escopo do projeto; e outros. As aes para correes das inconsistncias devem ser acompanhadas at que sejam resolvidas. 6.3.5 GRE5 - Mudanas nos requisitos so gerenciadas ao longo do projeto Durante o projeto, os requisitos podem mudar por uma srie de motivos. Desta forma, requisitos adicionais podem ser incorporados no projeto e/ou mudanas podem ser feitas nos requisitos j existentes. As necessidades de mudanas devem ser registradas e um histrico das decises acerca dos requisitos deve estar disponvel. Estas decises so tomadas por meio da realizao de anlises de impacto da mudana no projeto e podem incluir aspectos como: influncia em outros requisitos, expectativa dos interessados, esforo, cronograma, riscos e custo. 7 Os atributos de processo no nvel G

De acordo com o Guia Geral do MR-MPS, a capacidade do processo representada por um conjunto de atributos de processo descrito em termos de
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 20/26

resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalizao com que o processo executado na organizao. No MR-MPS, medida que a organizao evolui nos nveis de maturidade, um maior nvel de capacidade para desempenhar o processo deve ser atingido pela organizao [MRMPS, 2007a]. Vale, ainda, ressaltar que Os nveis so acumulativos, ou seja, se a organizao est no nvel F, esta possui o nvel de capacidade do nvel F que inclui os atributos de processo dos nveis G e F para todos os processos relacionados no nvel de maturidade F (que tambm inclui os processos do nvel G) [MR-MPS, 2007a]. No que se refere aos atributos de processo, para atingir o nvel G do MR-MPS, uma organizao deve atender aos resultados esperados RAP1 a RAP8. Numa avaliao, segundo o MA-MPS [MA-MPS, 2007b], exigido, para se considerar um processo SATISFEITO ao nvel G, que os atributos de processo AP 1.1 e AP 2.1 sejam caracterizados como T (Totalmente implementado) ou L (Largamente implementado). A seguir, os atributos de processo AP 1.1 e AP 2.1 so descritos com detalhes. 7.1 AP 1.1 - O processo executado Este atributo uma medida do quanto o processo atinge o seu propsito. Este atributo de processo est diretamente relacionado ao atendimento do propsito do processo. Relacionado a este atributo de processo est definido o seguinte resultado esperado: 7.1.1 RAP1 - O processo atinge seus resultados definidos Este resultado esperado busca garantir que o processo transforma produtos de trabalho de entrada identificveis em produtos de trabalho de sada, tambm identificveis, permitindo, assim, atingir o propsito do processo. Ou seja, este resultado implica diretamente na gerao dos principais produtos requeridos pelos resultados dos processos. 7.2 AP 2.1 - O processo gerenciado Este atributo uma medida do quanto a execuo do processo gerenciada. Este atributo de processo est relacionado gerncia dos processos. A implementao deste atributo de processo implica no planejamento da execuo do processo, atribuindo responsabilidade e autoridade para sua execuo, bem como fornecendo recursos adequados. Envolve tambm o monitoramento e controle da execuo dos processos, tomando aes corretivas, quando necessrias. Relacionados a este atributo de processo esto definidos os seguintes resultados esperados: 7.2.1 RAP2 - Existe uma poltica organizacional estabelecida e mantida para o processo Este resultado visa definio das expectativas organizacionais para a execuo dos processos, bem como disponibiliz-las a todos os interessados em sua execuo.
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 21/26

A poltica define um conjunto de diretrizes de como a organizao planeja e implementa os seus processos. Isso pode incluir princpios bsicos, definies gerais de como fazer, incluindo aspectos de responsabilidades, tempos e instrumentos. A poltica no deve ser uma reproduo de textos do MR-MPS, mas sim, como a organizao enxerga seus processos. Pode existir um documento genrico onde se defina quem tem autoridade, delegada pela gerncia de alto nvel, para aprovar cada tipo de documento. A poltica relativa a um processo deve conter as diretrizes para o cumprimento deste na organizao. Em geral, os aspectos mais importantes do processo devem ter a indicao de como devem ser atendidos. Normalmente as polticas so definidas junto gerncia de alto nvel e podem definir a expectativa para execuo de um ou vrios processos. No h obrigatoriedade de estarem rotuladas como polticas. Uma vez definidas, as polticas devem ser publicadas e divulgadas aos interessados. Tal publicao pode ser realizada, por exemplo, na Intranet da organizao. 7.2.2 RAP3 - A execuo do processo planejada Este resultado visa realizao de um plano para a execuo do processo. Este planejamento deve incluir recursos, responsabilidades e tempo, bem como as atividades de controle e monitoramento da execuo do processo. Deve ser estabelecido e documentado um plano para a execuo do processo, o que inclui sua prpria descrio. importante que o planejamento seja revisto, sempre que necessrio, especialmente quando forem aprovadas mudanas significativas no projeto. 7.2.3 RAP4 - (Para o nvel G) A execuo do processo monitorada e ajustes so realizados para atender aos planos Este resultado s se aplica ao nvel G e visa monitorar a execuo dos processos conforme o que foi planejado e assegurar que aes corretivas sejam tomadas sempre que houver desvios significativos em relao ao planejado. Desta forma, revises das atividades, estado e resultados dos processos devem ser realizadas, e podem ocorrer tanto periodicamente ou motivadas por algum evento. Durante o monitoramento dos processos, questes podero ser identificadas, para as quais aes corretivas devero ser tomadas e acompanhadas at o seu encerramento. O monitoramento do processo pode ser includo nas prprias atividades de monitoramento do projeto. 7.2.4 RAP5 - Os recursos necessrios para a execuo do processo so identificados e disponibilizados Este resultado visa assegurar que os recursos necessrios para executar o processo sero identificados previamente, e que estaro disponveis quando forem necessrios. Incluem recursos financeiros, condies fsicas adequadas, pessoal e ferramentas apropriadas (incluindo processos e modelos de documentos predefinidos).
MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007 22/26

Estes recursos podem estar estabelecidos na prpria descrio de processo ou podem, tambm, estar presentes em planos especficos para os processos nos nveis da organizao e/ou projeto. 7.2.5 RAP6 - As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia Este resultado visa assegurar que as pessoas tenham as habilidades e conhecimentos necessrios para executar ou apoiar o processo. Deve-se assegurar que as pessoas tenham o conhecimento em relao ao seu papel no processo: conhecimento completo para aqueles que vo realizar as atividades do processo e conhecimento genrico para os que vo interagir com o processo. Conhecimento e habilidades no devem se restringir aos documentos de processo, mas podem incluir trabalho em grupo, liderana, anlise e soluo de problemas. Quando necessrio, um treinamento apropriado deve ser fornecido para as pessoas que iro executar os processos. Os treinamentos podem ser: treinamento autodirecionado; instruo programada autodefinida; treinamento formal dentro do trabalho; mentoring; e treinamento formal em salas de aula. Mantendo-se o registro das competncias atuais e necessrias das pessoas para a realizao dos diversos papis na execuo dos processos, pode-se planejar os treinamentos necessrios. 7.2.6 RAP7 - A comunicao entre as partes interessadas no processo gerenciada de forma a garantir o seu envolvimento no projeto O objetivo deste resultado identificar as partes interessadas no processo, planejar e manter o seu envolvimento. Os interessados podem ser envolvidos tipicamente em atividades tais como: planejamento; coordenao; reviso; e definio dos requisitos para a execuo do processo. importante gerenciar a interface entre as partes interessadas de forma a assegurar a comunicao. 7.2.7 RAP8 - Mtodos adequados para monitorar a eficcia e adequao do processo so determinados O objetivo deste resultado fornecer visibilidade com relao ao estado da execuo dos processos, considerando sua adequao ao projeto, operao com recursos apropriados e alcance dos resultados esperados pelo projeto. Um dos mtodos de monitorao de processo a reviso, junto gerncia de alto nvel, de seu estado, atividades realizadas e resultados alcanados. As revises devem ocorrer periodicamente ou motivadas por algum evento e no necessitam ser presenciais. Desta forma, o andamento da implantao dos processos, tendncias e problemas so relatados e tratados em nveis apropriados. Caso pertinente, aes corretivas so estabelecidas e gerenciadas at a sua concluso, com escalonamento aos nveis adequados de gerncia, sempre que necessrio.

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

23/26

Referncias bibliogrficas [CMU/SEI, 2006] - SOFTWARE ENGINEERING INSTITUTE - SEI. CMMI for Development, Version 1.2, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, agosto, 2006. Disponvel em: http://www.sei.cmu.edu, verificado em Maro/2007. [DORFMANN e THAYER, 1990] DORFMANN, M. e THAYER, R. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990. [IEEE Std 610.12, 1990] Std 610.12 - IEEE Standard Glossary of Software Engineering Terminology, Institute of Electrical and Electronics Engineers, 1990. [ISO/IEC 12207:1995/Amd 1:2002] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207 Amendment: Information Technology - Amendment 1 to ISO/IEC 12207, Geneve: ISO, 2001. [ISO/IEC 12207:1995] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC 12207: Information technology Software life cycle processes, Geneve: ISO, 1995. [ISO/IEC 15271:1998] the International Organization for Standardization and the International Electrotechnical Comission. ISO/IEC TR 15271: Information Technology Guide for ISO/IEC 12207 (Software life cycle processes), Geneve: ISO, 1998. [MPS.BR, 2007a] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral, v 1.2, 2007. Disponvel em www.softex.br [MPS.BR, 2007b] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Avaliao, v 1.1, 2007. Disponvel em www.softex.br [MPS.BR, 2007c] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Aquisio, v 1.2, 2007. Disponvel em www.softex.br [PMBOK, 2004] - PROJECT MANAGEMENT INSTITUTE PMI. A Guide to the Project Management Body of Knowledge - PMBOK, Syba: PMI Publishing Division, 2004. Disponvel em: <www.pmi.org>. [VAZQUEZ et al., 2005] VAZQUEZ, C. E.; SIMES, G. S; ALBERT, R. M. Anlise de Pontos de Funo Medio, Estimativas e Gerenciamento de Projetos de Software. Editora rica, So Paulo, 3.ed. 2005.

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

24/26

Lista de colaboradores do Guia de Implementao Parte 1 verso 1.1 Julho/2007

Editoras: Ana Regina C. Rocha Ana Liddy C. C. Magalhes Colaboradores Mariano Angel Montoni Revisores: Danilo Scalet Edmia Leonor Pereira de Andrade CELEPAR MAPA COPPE/UFRJ COPPE/UFRJ (Coordenadora da ETM) SwQuality

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

25/26

Lista de colaboradores do Guia de Implementao Parte 1 verso 1.0 Dezembro/2006

Editoras: Ana Cristina Rouiller Ana Regina C. Rocha Kthia Maral de Oliveira Colaboradores: Alfredo Nozomu Tsukumo Clnio Figueiredo Salviano Geovane Nogueira Lima Heron Vieira Aguiar Marblia Passagnolo Srgio Renata Telles Moreira Sandro Ronaldo Bezerra Oliveira Wagner Roberto De Martino Revisores: Ana Regina C. Rocha Danilo Scalet Kthia Maral de Oliveira Mariano Angel Montoni COPPE/UFRJ (Coordenadora da ETM) CELEPAR Universidade Catlica de Braslia COPPE/UFRJ CenPRA CenPRA SWQuality SWQuality CenPRA SWQuality SWQuality CenPRA UFRPE / SWQuality COPPE/UFRJ (Coordenadora da ETM) Universidade Catlica de Braslia

MPS.BR Guia de Implementao Parte 1 V1.1 Julho/2007

26/26