Guia de Implementacao Parte 1 2011

MPS.
BR - Melhoria de Processo do Software Brasileiro
Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS
Este guia contm orientaes para a implementao do nvel G do Modelo de Referncia MR-MPS. VIGNCIA E TRANSIO: O Guia Geral:2011 entra em vigor em 30 de junho de 2011. Assim, a partir desta data podem ser realizadas avaliaes MPS usando o modelo de referncia MR-MPS:2011. Entretanto, fica definido um perodo de transio, de 30 de junho a 31 de dezembro de 2011, durante o qual podem ser realizadas avaliaes MPS usando o modelo de referncia MR-MPS:2011 ou a verso anterior MR-MPS:2009. A partir de 1 de janeiro de 2012 s sero vlidas avaliaes MPS usando o modelo de referncia MR-MPS:2011. As implementaes a serem feitas utilizando este Guia de Implementao devero levar em conta estas vigncias.
Julho de 2011 Copyright 2011 - SOFTEX Direitos desta edio reservados pela Sociedade SOFTEX A distribuio ilimitada desse documento est sujeita a copyright ISBN 978-85-99334-24-9
Sumrio 1 2 3 4 Prefcio ............................................................................................................... 3 Introduo ........................................................................................................... 5 Objetivo ............................................................................................................... 6 Comeando a implementao do MR-MPS pelo nvel G .................................... 6
5 Gerncia de Projetos (GPR)................................................................................ 7 5.1 Propsito.......................................................................................................... 7 5.2 Fundamentao terica ................................................................................... 8 5.3 Resultados esperados ................................................................................... 10 6 Gerncia de Requisitos (GRE) .......................................................................... 29 6.1 Propsito........................................................................................................ 29 6.2 Fundamentao terica ................................................................................. 30 6.3 Resultados esperados ................................................................................... 32 7 Os atributos de processo no nvel G ................................................................. 38 7.1 AP 1.1 - O processo executado .................................................................. 39 7.2 AP 2.1 - O processo gerenciado ................................................................. 39 Referncias bibliogrficas......................................................................................... 43 Lista de colaboradores do Guia de Implementao Parte 1:2011 ......................... 45 Lista de colaboradores do Guia de Implementao Parte 1:2009 ......................... 46 Lista de colaboradores do Guia de Implementao Parte 1 verso 1.1 Julho/2007 ................................................................................................................................. 47 Lista de colaboradores do Guia de Implementao Parte 1 verso 1.0 Dezembro/2006 ........................................................................................................ 48
MPS.BR Guia de Implementao Parte 1:2011
2/48
Prefcio
O MPS.BR1 um programa mobilizador, de longo prazo, criado em dezembro de 2003, coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), que conta com apoio do Ministrio da Cincia e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Servio Brasileiro de Apoio s Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID). O objetivo do programa MPS.BR (acrnimo) a Melhoria de Processo do Software Brasileiro, com duas metas a alcanar a mdio e longo prazos: a) meta tcnica, visando criao e aprimoramento do modelo MPS, com resultados esperados tais como: (i) guias do modelo MPS; (ii) Instituies Implementadoras (II) credenciadas para prestar servios de consultoria de implementao do modelo de referncia MR-MPS; (iii) Instituies Avaliadoras (IA) credenciadas para prestar servios de avaliao seguindo o mtodo de avaliao MA-MPS; (iv) Consultores de Aquisio (CA) certificados para prestar servios de consultoria de aquisio de software e servios relacionados; b) meta de mercado, visando disseminao e adoo do modelo MPS, em todas as regies do pas, em um intervalo de tempo justo, a um custo razovel, tanto em PME (foco principal) quanto em grandes organizaes pblicas e privadas, com resultados esperados tais como: (i) criao e aprimoramento do modelo de negcio MN-MPS; (ii) cursos, provas e workshops; (iii) organizaes que implementaram o modelo MPS; (iv) organizaes com avaliao MPS publicada (prazo de validade de trs anos). O 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). Por meio 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. Cabe ao FCC: (i) emitir parecer que subsidie deciso da SOFTEX sobre o credenciamento de Instituies Implementadoras (II) e Instituies Avaliadoras (IA); (ii) monitorar os resultados das Instituies Implementadoras (II) e Instituies Avaliadoras (IA), emitindo parecer propondo SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS. Cabe ETM apoiar a SOFTEX sobre os aspectos tcnicos relacionados ao Modelo de Referncia (MR-MPS) e Mtodo de Avaliao (MA-MPS), para: (i) criao e aprimoramento contnuo do MR-MPS, MA-MPS e seus guias especficos; (ii) capacitao de pessoas por meio de cursos, provas e workshops.
MPS.BR, MR-MPS, MA-MPS e MN-MPS so marcas da SOFTEX. A sigla MPS.BR est associada ao programa MPS.BR Melhoria do Processo de Software Brasileiro e a sigla MPS est associada ao modelo MPS Melhoria do Processo de Software. MPS.BR Guia de Implementao Parte 1:2011 3/48
. A criao e o aprimoramento deste Guia de Implementao so tambm atribuies da ETM, sendo que este guia faz parte do seguinte conjunto de documentos do modelo MPS:

Guia Geral: 2009 [SOFTEX, 2011a]; Guia de Implementao (partes 1 a 11); Guia de Avaliao:2009 [SOFTEX, 2011b]; e Guia de Aquisio:2009 [SOFTEX, 2011c].
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 onze partes, contemplando, respectivamente, os seguintes nveis de maturidade:

Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS; Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS; Parte 3: Fundamentao para Implementao do Nvel E do MR-MPS; Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS; Parte 5: Fundamentao para Implementao do Nvel C do MR-MPS; Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS; Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS; Parte 8: Implementao do MR-MPS (Nveis G a A) em organizaes que adquirem software; Parte 9: Implementao do MR-MPS (Nveis G a A) em organizaes do tipo Fbrica de Software; Parte 10: Implementao do MR-MPS (Nveis G a A) em organizaes do tipo Fbrica de Teste;e Parte 11: Implementao e Avaliao do MR-MPS (Nveis G a A) em conjunto com o CMMI-DEV.
As alteraes deste Guia de Implementao em relao verso 2009 so decorrentes de:

mudanas realizadas na verso 2009 do Guia Geral; correo ortogrfica e gramatical; adequao das referncias bibliogrficas; incluso de notas explicativas contidas nas partes 8, 9 e 10 do Guia de Implementao; clarificao sobre o foco do resultado esperado GPR7.
4/48
incluso de explicao sobre a no necessidade de os requisitos serem avaliados utilizando critrios objetivos por todos os membros da equipe tcnica durante a reorganizao dos resultados esperados GRE1 e GRE2. incluso de pargrafo sobre itens rastreveis em um projeto na explicao sobre o resultado esperado GRE3. Introduo
As mudanas que esto ocorrendo nos ambientes de negcios tm motivado as empresas a modificar estruturas organizacionais e processos produtivos, saindo da viso tradicional baseada em reas funcionais em direo a redes de processos centrados no cliente. 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 se 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. Busca-se que o modelo MPS 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 se espera que o modelo MPS seja compatvel com os padres de qualidade aceitos internacionalmente e que tenha 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, estando em consonncia com as principais abordagens internacionais para definio, avaliao e melhoria de processos de software. O modelo MPS 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 modelo MPS possui trs componentes: Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-MPS) e Modelo de Negcio (MN-MPS). O modelo MPS est descrito por meio de documentos em formato de guias:
Guia Geral: contm a descrio geral do modelo MPS e detalha o Modelo de Referncia (MR-MPS), seus componentes e as definies comuns necessrias para seu entendimento e aplicao [SOFTEX, 2011a].
5/48
Guia de Aquisio: descreve um processo de aquisio de software. descrito de forma a apoiar as instituies que queiram adquirir produtos de software apoiando-se no MR-MPS [SOFTEX, 2011c]. Guia de Avaliao: descreve o processo e o mtodo de avaliao MA-MPS, os requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA) [SOFTEX, 2011b]. Guia de Implementao: srie de onze 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 a Instituies Implementadoras (II). O contedo deste documento informativo, ou seja, no se espera que uma organizao implementando o MR-MPS atenda a todos os itens citados na explicao referente aos resultados esperados. As observaes presentes neste documento procuram apenas explicitar elementos importantes na interpretao dos resultados esperados. Durante uma avaliao MPS, s requerido o atendimento aos resultados esperados definidos no Guia Geral. Os avaliadores MPS devem analisar se a implementao dos processos na organizao atende a cada resultado, com abertura a mltiplas formas vlidas de implementao. 4 Comeando a implementao do MR-MPS 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. No nvel G, o projeto pode usar os seus prprios padres e procedimentos, no sendo necessrio que se tenha padres organizacionais. Se, porventura, a organizao possuir processos j definidos e os projetos necessitarem adaptar os processos existentes, deve-se registrar essa adaptao durante o planejamento do projeto. Adaptaes podem incluir alterao em processos, atividades, ferramentas, tcnicas, procedimentos, padres, medidas, dentre outras.
MPS.BR Guia de Implementao Parte 1:2011 6/48
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 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. Um marco um ponto de reviso, 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 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. Pontos de controle representam pontos entre um marco e outro nos quais revises so realizadas para avaliar o andamento do projeto, porm, no esto no caminho crtico do projeto, ou seja, o projeto pode prosseguir mesmo que a reviso de um ponto de controle no tenha sido concluda. 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 deste processo so apresentadas nas partes 3 e 6 do Guia de Implementao.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) No so permitidas excluses de resultados deste processo. No so permitidas excluses de resultados deste processo. No so permitidas excluses de resultados deste processo.
5.2 Fundamentao terica Antes de discorrer sobre gerenciamento de projetos, conveniente definir o que um projeto. No MPS.BR, a definio de projeto Um empreendimento realizado para criar um produto. O projeto se caracteriza por temporalidade e resultado, produto nico e elaborao progressiva [SOFTEX, 2011a]. A temporalidade na definio de projeto significa que todos os projetos possuem um incio e um fim bem definidos e estabelecidos. O fim do projeto atingido quando os objetivos do projeto tiverem sido alcanados, quando se tornar claro que os objetivos no sero ou no podero ser alcanados ou ainda quando o projeto for cancelado. O termo produto 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 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, por exemplo, so planejadas, executadas e controladas por pessoas e tm restries de recursos. As operaes e os projetos diferem principalmente no que diz respeito temporalidade, 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 estabelece 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 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) [PMI, 2008]. 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. O gerenciamento de projeto na viso do PMBOK [PMI, 2008] 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 identifica, estabelece, coordena e produz um produto, de acordo com seus requisitos. O IEEE (Institute of Electrical and Electronics Engineers), em seu Glossrio Padro de Terminologias da Engenharia de Software [IEEE, 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, no contexto dos requisitos e restries do projeto [ISO/IEC, 2008]. 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 [PMI, 2008].
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) As organizaes que adquirem software devem planejar as tarefas do fornecedor de forma macroscpica e as suas prprias tarefas de forma detalhada. Aps a contratao, dados do planejamento do projeto no fornecedor podem ser incorporados ao planejamento do projeto na organizao adquirente. As atividades relacionadas monitorao do projeto so de grande importncia para as organizaes adquirentes para assegurar, por um lado, que suas tarefas esto sendo executadas conforme o planejado e, por outro, para monitorar a execuo do contrato pelo fornecedor [HOFMANN et al., 2007]. Em organizaes do tipo Fbrica de Software, o gerenciamento do projeto pode ser realizado da mesma forma que para outros tipos de organizao. A diferena normalmente reside no escopo do trabalho que foca a etapa de construo (implementao) de cdigo. As organizaes do tipo Fbrica de Teste devem definir o seu projeto de acordo com as atividades para as quais foi contratada, ou seja, o teste do produto de software. A Fbrica de Teste pode ser responsvel pelo desenvolvimento dos casos de testes e estes podem ser desenvolvidos paralelamente ao desenvolvimento e/ou manuteno do produto de software. Neste caso, o planejamento do projeto da Fbrica de Teste deve ser negociado de forma integrada ao desenvolvimento/manuteno do produto de software e quaisquer desvios podem levar a um replanejamento.
Fbrica de Software (Parte 9)
Fbrica de Teste (Parte 10)
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 que satisfaa as necessidades, caractersticas e funes especificadas para o projeto, de forma a conclu-lo com sucesso. 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, o escopo em geral contm a definio do objetivo e da motivao, os limites e
restries, todos os produtos que sero entregues e os outros produtos gerados pelo projeto, entre outras informaes. 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) A definio do escopo do trabalho quando h aquisio deve deixar claro o que responsabilidade do adquirente e o que responsabilidade do fornecedor. Em organizaes do tipo Fbrica de Software importante deixar claro o que responsabilidade do contratante do servio, uma vez que normalmente apenas uma parte do ciclo de vida (codificao) compe o escopo do projeto que ser desenvolvido pela Fbrica de Software. importante inserir na documentao do escopo, a etapa referente recepo/compreenso das especificaes que, neste caso, constituem uma parte relevante das atividades iniciais de uma Fbrica de Software. igualmente importante inserir na documentao do escopo quais so as etapas de teste que sero desempenhadas pela Fbrica de Software. Fbrica de Teste (Parte 10) A definio do escopo de trabalho deve deixar claro o que responsabilidade do desenvolvedor do produto e da Fbrica de Teste em relao aos testes. Variaes no escopo de trabalho podem incluir, por exemplo: O desenvolvimento dos casos de testes pela organizao desenvolvedora ou pela Fbrica de Teste; A necessidade de serem executados pela organizao desenvolvedora testes unitrios nos componentes do produto, antes destes serem enviados para a Fbrica de Teste; Os tipos de teste que devem ser executados pela Fbrica de Teste; A contratao especfica de tipos de teste para cada componente do software.
11/48
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, porm ser obrigatria a partir do nvel E. No nvel G, 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. Uma organizao pode tambm aplicar tcnicas de estimativas prprias que se mostraram eficientes e adequadas s necessidades e caractersticas da empresa.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Para organizaes adquirentes, a estimativa precisa de tamanho essencial para se poder estabelecer, com segurana, o acordo com o fornecedor. Desta forma, embora no Nvel G do MPS no seja exigido o uso de tcnicas de estimativa, muito conveniente que estas sejam utilizadas. Em organizaes do tipo Fbrica de Software, a estimativa precisa de tamanho essencial para estabelecer, com segurana, os parmetros do contrato. Neste caso, esta estimativa tambm mais factvel de ser obtida, uma vez que o produto j est especificado em nvel mais detalhado, o que tende a garantir maior preciso na estimativa. Embora tcnicas de estimativa mais elaboradas no sejam exigidas no Nvel G do MPS, muito comum que sejam parte da negociao de contratos em organizaes do tipo Fbrica de Software.
12/48
Para a Fbrica de Teste o estabelecimento de estimativas poder considerar o nmero de vezes em que os testes devero ser executados, visto que, a depender da qualidade do produto entregue, pode ser necessrio que os testes sejam repetidos e um esforo maior seja acrescentado. Como consequncia, as estimativas de trabalho podem estipular uma quantidade de testes a serem aplicados e isto estar definido em contrato.
5.3.3 GPR3 - O modelo e as fases do ciclo de vida do projeto so definidos O ciclo de vida de um projeto consiste de fases e atividades que so 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, que por sua vez geram 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. 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 sequenciais ou cascata, modelos incrementais e modelos evolutivos [ISO/IEC, 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 [ISO/IEC, 1998] a aplicao de cada modelo de ciclo de vida detalhada. No entanto, outros tipos de modelos de ciclo de vida tm sido cada vez mais adotados pelas organizaes, como o RUP (Rational Unified Process) [KRUCHTEN, 2003] e suas variaes. 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 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.
13/48
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) O adquirente e o fornecedor no necessariamente utilizam o mesmo modelo de ciclo de vida. A definio do modelo de ciclo de vida a ser utilizado pelo fornecedor pode, ou no, fazer parte do acordo estabelecido entre o adquirente e o fornecedor. Em qualquer caso, entretanto, o adquirente deve conhecer e aprovar o modelo de ciclo de vida utilizado pelo fornecedor. Alm disso, a interao entre o modelo de ciclo de vida utilizado pelo adquirente e o utilizado pelo fornecedor devem estar bem definidas. Em algumas situaes onde o fornecedor no possuir um processo de desenvolvimento e, como consequncia, tambm no utilizar um modelo de ciclo de vida adequado e explicitamente definido, a organizao adquirente pode estabelecer um ciclo de vida a ser utilizado no projeto, com atividades e verificaes que garantam se atingir os objetivos do projeto. Fbrica de Software (Parte 9) As organizaes do tipo Fbrica de Software geralmente executam apenas uma parte do ciclo de vida, que corresponde s atividades de implementao (codificao) e testes unitrios ou em nvel de mdulos. importante detalhar como o ciclo de vida ser organizado e como as entregas parciais ocorrero, se for o caso. Entregas parciais devem ser planejadas junto organizao contratante, de modo a sincroniz-las com o projeto de desenvolvimento como um todo. Uma etapa essencial neste tipo de organizao a de recepo, compreenso e aceitao das especificaes recebidas, que deve preceder o incio da codificao. Refira-se a GRE1 para maiores detalhes desta etapa. Fbrica de Teste (Parte 10) O modelo de ciclo de vida definido para ser implementado no projeto da Fbrica de Teste tende a ser o mesmo utilizado para o desenvolvimento e/ou manuteno do produto de software. Por exemplo, se utilizado um modelo de ciclo de vida incremental, os testes tambm podem ser definidos com este ciclo de vida. A Fbrica de Teste pode optar, em comum acordo com a contratante, em realizar um ciclo de vida em que as fases dos testes sejam executadas em paralelo ao desenvolvimento do produto. Neste caso, durante a especificao do produto, os casos de testes tambm so especificados e to logo os componentes do produto estejam prontos, os testes so realizados. Esta abordagem tende a agilizar o processo de teste e faz com que o produto seja testado antecipadamente, permitindo uma viso prvia da sua qualidade.
14/48
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 tecnologia adotada, experincia do profissional, grau de ineditismo do servio para a organizao ou para os profissionais alocados. Empresas implementando o nvel G do MR-MPS geralmente no possuem bases de dados histricas. Entretanto, para alcanar nveis superiores de maturidade preciso que essa base seja construda e os dados obtidos pelos projetos executados, mesmo no nvel G, so fortes candidatos a aliment-la.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) As estimativas de esforo e custo devem ser feitas pelo adquirente de forma detalhada para as tarefas que executar e de forma macroscpica para as tarefas a serem executadas pelo fornecedor. Para as organizaes do tipo Fbrica de Software mais vivel obter estimativas de maior preciso, uma vez que estas se baseiam em especificaes mais detalhadas. Devido ao seu escopo reduzido de atuao (etapa de codificao), as bases histricas tendem a refletir mais precisamente o relacionamento entre tamanho e esforo. Sem comentrio adicional para este resultado.
15/48
5.3.5 GPR5 - O oramento e o cronograma do projeto, incluindo a definio de marcos e 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. Uma forma de se definir o cronograma utilizando a EAP e as estimativas de esforo e custo (GPR4), considerando as dependncias entre as tarefas e os marcos e 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. O oramento do projeto estabelecido com base no cronograma e na estimativa de custos. 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Aps a contratao do fornecedor, o adquirente deve incorporar no seu cronograma, marcos e pontos de controle onde far a monitorao do projeto e do fornecedor. Deve, tambm, incorporar no oramento do projeto o momento e o valor de cada desembolso para o fornecedor. Para as organizaes do tipo Fbrica de Software importante definir certas pr-condies para o incio de algumas de suas atividades, como, por exemplo, o recebimento das especificaes vindas da contratante. Em uma organizao do tipo Fbrica de Software, muitas das dependncias que podem gerar gargalos sero provenientes de atividades da contratante. Para organizaes do tipo Fbrica de Teste importante definir certas pr-condies para incio de algumas de suas atividades como, por exemplo, o recebimento do cdigo vindo da contratante.
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 tm riscos e estes precisam ser identificados, analisados e priorizados. Para facilitar a identificao dos riscos, interessante elaborar uma lista de riscos mais comuns a 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. A monitorao dos riscos garantida pelo resultado esperado GPR15. Os problemas gerados devido materializao de riscos podem ser registrados de acordo com os requisitos do resultado GPR18 e acompanhados de acordo com os requisitos do resultado GPR19. Os riscos identificados devem ser registrados, bem como o acompanhamento dos seus estados e aes tomadas. Uma planilha de riscos, contendo dados como identificador, descrio, probabilidade, impacto e prioridades no seu tratamento, pode ser utilizada para identificao dos riscos, monitorao dos riscos identificados e atualizao da lista de riscos do projeto medida que novos riscos forem sendo identificados. importante demonstrar que esta planilha est sendo monitorada e atualizada. 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). No nvel G, os riscos so acompanhados para verificar como afetam o projeto e para se tomar aes, mesmo que ainda sem um gerenciamento completo (previsto a partir do nvel C do MPS pela incorporao do processo Gerncia de Riscos).
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Alm dos riscos para o projeto que podem ter origem no ambiente do adquirente, projetos que envolvem fornecedores esto sujeitos a riscos vindos do acordo estabelecido entre o adquirente e o fornecedor e/ou de caractersticas do fornecedor. Estes riscos precisam ser identificados para poderem ser monitorados. Para as organizaes do tipo Fbrica de Software, alm dos riscos oriundos do prprio projeto, devem ser levados em considerao os riscos advindos da contratante, como, por exemplo, a no entrega das especificaes na data planejada ou at mesmo a entrega de especificaes em qualidade inferior ao necessrio para o incio da codificao. Alm dos riscos oriundos do prprio projeto da Fbrica de Teste, devem ser levados em considerao os riscos advindos da contratante como, por exemplo, a no entrega dos cdigos na data planejada ou uma quantidade e severidade de problemas que impeam a realizao dos testes planejados.
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 necessidades de treinamento. A existncia de registros das necessidades e disponibilidade evita a alocao com base em critrios subjetivos. Este resultado esperado possui dois pontos principais: (i) planejamento prvio das necessidades de pessoal em relao a competncias (conhecimento, habilidades, atitudes e experincias) para que as tarefas previstas no decorrer do projeto possam ser executadas de forma adequada e de acordo com a responsabilidade esperada; (ii) a alocao dos recursos humanos ao projeto de acordo com o planejamento realizado. Dessa forma, este resultado implica que o planejamento da alocao de recursos humanos com base na anlise de suas competncias possudas e requeridas para desempenhar as tarefas no projeto. Caso uma pessoa seja alocada ao projeto sem ter as competncias necessrias, o risco pode ser minimizado, por exemplo, com aes de treinamento e mentoring ou supervisionando-se o trabalho da pessoa por um membro melhor capacitado. O treinamento inclui todas as atividades realizadas para aprimorar as competncias dos membros da equipe do projeto, podendo ser formal ou informal. Exemplos de mtodos para realizao de treinamentos incluem treinamento em sala de aula, online, baseado em computador, no trabalho, leituras, aconselhamento e orientaes.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) O adquirente responsvel por identificar os perfis e conhecimento necessrios para executar o projeto, tanto de seu prprio pessoal, quanto dos recursos humanos a serem providos pelo fornecedor, de forma a garantir uma alocao adequada de pessoal ao projeto. Aps a alocao da equipe pelo fornecedor, pode verificar a adequao do pessoal alocado por meio de anlise das comprovaes pertinentes. O adquirente pode ser responsvel por treinamentos para o fornecedor (por exemplo: treinamento no domnio do problema), caso isto faa parte do acordo estabelecido. Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Sem comentrio adicional para este resultado.
18/48
5.3.8 GPR8 - (At o nvel F) Os recursos e o ambiente de trabalho necessrios para executar o projeto so planejados Este resultado faz referncia necessidade de se planejar, com base na EAP (ou estrutura equivalente), 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 a ser adquirido 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) O adquirente deve planejar os recursos e o ambiente de trabalho necessrios para executar o projeto, identificando o que ele mesmo deve prover e o que responsabilidade do fornecedor. Em organizaes do tipo Fbrica de Software tambm pode ser necessrio planejar os recursos especficos relacionados compatibilidade com o ambiente da contratante, o que inclui: recursos para os testes unitrios ou de mdulos, disponibilizao de infraestrutura para acesso remoto a repositrios da contratante, treinamento em ferramentas de uso da contratante etc. Sem comentrio adicional para este resultado.
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. 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 confidencialidade das informaes, mesmo quando no declarada pelo cliente, pode ter que ser tratada com cuidado. recomendvel, portanto, explicitar a existncia ou no de dados confidenciais. Se a organizao tem um critrio padro para execuo dessas atividades, isto deve ser registrado no plano do projeto ou em outro documento.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Este um aspecto crtico e que precisa estar explcito no acordo com o fornecedor. O Plano do Projeto deve conter a definio: (i) de como ser o fluxo de dados entre o adquirente, o fornecedor e demais envolvidos no projeto; (ii) de como ser o acesso aos dados, reproduo, manipulao, alterao e transferncia de posse; (iii) de como os dados devero estar formatados [HOFMANN et al., 2007]. Sem comentrio adicional para este resultado.
Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)
Sem comentrio adicional para este resultado.
5.3.10 GPR10 - Um plano geral para a execuo do projeto estabelecido com a integrao de planos especficos O objetivo deste resultado esperado garantir que todos os planos que afetam o projeto estejam integrados e que a dependncia entre estes planos tenha sido identificada e levada em considerao durante o planejamento, conciliando o trabalho a ser realizado aos recursos e condies existentes. A realizao do planejamento do projeto garantida pelos resultados esperados no escopo do nvel G do MR-MPS do processo Gerncia de Projetos (GPR), que prev, dentre outros, a criao do cronograma de atividades, o planejamento de recursos humanos, custos, riscos, dados etc. 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. Esta integrao entre os planos pode
acontecer de vrias formas, entre elas: cronograma gerado com base nas atividades previstas para o projeto; plano de custos derivado do custo de cada profissional contemplado no plano de recursos humanos; plano de treinamentos derivado das tarefas a serem realizadas no projeto e das habilidades e competncias dos colaboradores, conforme o plano de recursos humanos. importante 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 maior visibilidade ao projeto, facilitando em muito no s o seu gerenciamento, mas tambm a formao de uma base histrica. Esta base histrica 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. 5.3.11 GPR11 - A viabilidade de atingir as metas do projeto explicitamente avaliada considerando restries e recursos disponveis. 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). Pode-se considerar tambm os objetivos de negcio e a composio do portflio de projetos da organizao. Muitas vezes prefervel no iniciar ou parar um projeto j iniciado do que prosseguir com um projeto invivel, que pode implicar perdas maiores, tanto para o fornecedor como para o cliente. No incio do projeto, uma avaliao preliminar pode ser conduzida, a partir da viso geral dos objetivos e caractersticas dos resultados pretendidos, dos recursos financeiros, tcnicos e humanos, bem como de restries impostas pelo cliente, ambiente externo e interno, alm de condies para o desenvolvimento. medida que o projeto evolui, a viabilidade de sucesso pode ser reavaliada com mais preciso. As mudanas de requisitos so eventos que podem levar necessidade de reavaliar a viabilidade do projeto. De qualquer forma, a viabilidade do projeto deve ser avaliada de forma explcita. Muitas vezes esta avaliao feita de forma subjetiva ou automtica, o que pode aumentar os riscos da organizao em relao ao projeto sendo executado. Em marcos do projeto e mesmo durante as atividades de acompanhamento, pode ser necessria a confirmao da viabilidade de continuidade do projeto.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Atividades relacionadas monitorao do fornecedor pelo adquirente podem indicar no ser vivel a continuidade do projeto ou ser necessria a sua reviso. O acordo deve estabelecer mecanismos que possibilitem o seu cancelamento ou sua reviso conforme necessrio.
21/48
Um aspecto importante a ser considerado na anlise da viabilidade no caso de uma organizao do tipo Fbrica de Software, a qualidade das especificaes recebidas da contratante e a disponibilidade desta para esclarecimento de dvidas. Este aspecto pode levar inviabilidade do projeto. Um aspecto importante a ser considerado na anlise da viabilidade no caso de uma organizao do tipo Fbrica de Teste, a qualidade das especificaes recebidas da contratante para definir os casos de teste. Este aspecto pode levar inviabilidade do projeto.
5.3.12 GPR12 - O Plano do Projeto revisado com todos os interessados e o compromisso com ele obtido e mantido 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 existirem conflitos entre as diversas variveis do projeto, como requisitos, custos e 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. Ao longo do projeto, de acordo com a dinmica de sua execuo, novos interessados podem ser identificados e compromissos anteriormente obtidos podem precisar ser modificados ou revistos. Dessa forma, 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. Algumas organizaes costumam realizar uma reunio de incio de projeto (kick off) que pode ser utilizada para resolver os conflitos e obter o comprometimento tanto dos participantes internos do projeto quanto externos. Deve-se tomar cuidado, no entanto, para que seja obtido o comprometimento das pessoas que no tenham participado da reunio de incio de projeto por estarem ausentes ou terem sido alocadas a tarefas do projeto posteriormente. Outras organizaes utilizam ferramentas de alocao de tarefas ou gerenciamento de requisies (issue tracking systems) para a gerncia das tarefas a serem desempenhadas nos projetos. Nestes casos, uma alternativa seria condicionar o comprometimento de parte da equipe do projeto aceitao das tarefas alocadas. De qualquer forma, importante, para minimizar os riscos dos projetos, que o comprometimento dos envolvidos seja obtido antes da participao na execuo de alguma tarefa.Este resultado esperado est de certa forma associado ao GPR11, pois a realizao da anlise de viabilidade pode resultar em aes para soluo de conflitos que impactem no
comprometimento dos envolvidos com o projeto. A integrao dos planos e o planejamento global dos recursos da organizao tambm contribuem para a resoluo prvia de conflitos envolvendo, por exemplo, a alocao de profissionais compartilhados em diferentes projetos ou a conciliao de datas de profissionais das reas de apoio (por exemplo, Garantia da Qualidade e Gerncia de Configurao). 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Deve-se ter o compromisso dos participantes do projeto na organizao adquirente e o compromisso do fornecedor com as partes do plano, relacionadas s tarefas que executar. O compromisso do fornecedor pode ser realizado por meio de um representante definido no acordo estabelecido. Para as organizaes do tipo Fbrica de Software uma ateno especial na obteno do compromisso com os participantes externos ao projeto importante pelo alto grau de integrao e dependncia entre as atividades de codificao e especificao. Uma ateno especial na obteno dos compromissos com os participantes externos ao projeto importante pelo alto grau de integrao e dependncia entre as atividades de testes e os resultados do processo de desenvolvimento de software.
5.3.13 GPR13 - O escopo, as tarefas, as estimativas, o oramento e o cronograma do projeto so monitorados em relao ao planejado 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. Esta uma atividade essencial de gerenciamento: acompanhar o que foi planejado, detectar problemas e corrigi-los. O objetivo deste resultado esperado assegurar que haja monitorao do projeto em relao a aspectos relacionados s tarefas, estimativas, oramento e cronograma (ver GPR2, GPR3, GPR4, GPR5). Em geral, durante um monitoramento, faz-se uma anlise do que foi planejado anteriormente com os valores atuais das variveis consideradas. Por exemplo, o conjunto de tarefas planejadas inicialmente pode sofrer alteraes ao longo da execuo do projeto; estimativas precisam ser adequadas em decorrncia de alteraes no escopo do projeto em termos de tarefas e/ou trabalho previsto, adequaes de fatores de ajuste
de produtividade etc.; o oramento do projeto pode sofrer alteraes em decorrncia dos valores reais dos custos diretos e indiretos do projeto; parte das atividades presentes no cronograma do projeto pode estar atrasada ou adiantada. 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. Em todo o caso, o planejamento do projeto deve ser revisto para adequao dos itens pertinentes. Anlises devem ser realizadas e decises serem tomadas considerando-se as variaes dos dados e desvios entre resultados e valores atuais e esperados. Caso seja necessrio, planos de ao devem ser gerados (ver GPR18 e GPR19) para corrigir problemas ou evitar que outros problemas aconteam posteriormente.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) O adquirente deve gerenciar sua parte no projeto e, tambm, como o fornecedor est executando a sua parte de acordo com o acordo e com os planos estabelecidos e aprovados por ambos. A gerncia do projeto na organizao adquirente deve garantir a monitorao do projeto levando em considerao tambm a dependncia em relao s atividades executadas pelas empresas contratadas no projeto em questo. Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Sem comentrio adicional para este resultado.
5.3.14 GPR14 - Os recursos materiais e humanos bem como os dados relevantes do projeto so monitorados em relao ao planejado O objetivo deste resultado esperado garantir que o projeto seja monitorado em relao aos itens planejados referentes a recursos materiais e recursos humanos (ver GPR7 e GPR8). Em geral, durante um monitoramento, faz-se uma anlise do que foi planejado anteriormente com os valores atuais das variveis consideradas. Por exemplo, a sada de um membro da equipe pode disparar a alocao de uma nova pessoa ou, at mesmo, a contratao de um novo funcionrio na organizao. Da mesma forma, pode ser necessrio alocar um novo membro da equipe devido identificao de um novo perfil ou competncia para concluso de uma tarefa. Da mesma forma, pode ser necessria a compra de novos equipamentos ou softwares
ao longo da execuo do projeto. Outro ponto a ser considerado identificar se novos documentos devem ser includos no repositrio do projeto ou se os produtos de trabalho intermedirios do projeto esto de fato sendo produzidos e armazenados adequadamente. Em todo o caso, o planejamento do projeto deve ser revisto para adequao dos itens pertinentes. Caso seja necessrio, planos de ao devem ser gerados (ver GPR18 e GPR19) para corrigir problemas ou evitar que outros problemas aconteam posteriormente.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. O adquirente deve gerenciar sua parte no projeto e, tambm, como o fornecedor est executando a sua parte de acordo com o acordo e com os planos estabelecidos e aprovados por ambos. Sem comentrio adicional para este resultado.
5.3.15 GPR15 - Os riscos so monitorados em relao ao planejado No decorrer do projeto novos riscos podem ser identificados para o projeto e os parmetros dos riscos j identificados podem ser alterados (ver GPR6). Alm disso, pode ser necessrio executar aes de mitigao para evitar que os riscos aconteam ou, no caso de riscos terem se concretizado, pode ser preciso executar aes de contingncia para minimizar seus efeitos. Tambm importante que a lista de riscos seja reavaliada periodicamente em conjunto com uma avaliao dos seus parmetros de anlise (probabilidade e impacto) e prioridade. Alteraes realizadas no planejamento de riscos devem ser comunicadas aos interessados conforme pertinente. Caso seja necessrio, planos de ao devem ser gerados (ver GPR18 e GPR19) para corrigir problemas ou evitar que outros problemas aconteam posteriormente. Tambm pode ser necessrio rever o planejamento do projeto para adequao dos itens pertinentes.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) A gerncia do projeto na organizao adquirente deve garantir a monitorao dos riscos do projeto, que podem estar relacionados a aspectos que envolvam as empresas contratadas.
25/48
5.3.16 GPR16 - O envolvimento das partes interessadas no projeto planejado, monitorado e mantido 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, monitorado e mantido ao longo de todo o projeto. Os interessados no projeto podem incluir os clientes e os usurios (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 a pouca comunicao necessria em funo do curto prazo. A comunicao envolve, por exemplo, questes relativas a prazos, custos, recursos, comprometimentos e tambm requisitos, pois estes afetam as outras variveis. Um plano de gerenciamento das comunicaes pode cobrir este resultado esperado [PMI, 2008]. O distanciamento da gerncia do projeto em relao aos interessados pode acarretar desvios em relao s reais necessidades que o projeto dever atender. 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. indicado que os fornecedores de requisitos e representantes do cliente saibam antecipadamente o momento em que devero se envolver no projeto e o que se espera desta participao. O mesmo deve ser aplicado aos membros da equipe do projeto.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) A gerncia do projeto na organizao adquirente deve garantir o envolvimento das partes interessadas internas organizao e o envolvimento do fornecedor. Para as organizaes do tipo Fbrica de Software importante o monitoramento das atividades externas, que dependem da contratante como, por exemplo, a entrega das especificaes na data acordada.
26/48
O envolvimento dos interessados essencial para analisar se o projeto continua com os objetivos iniciais ou se estes foram alterados. Manter o envolvimento dos interessados e do contratante nos resultados dos testes pode subsidiar o contratante com informaes que o ajudaro a tomar decises importantes em relao manuteno da qualidade do produto de software.
5.3.17 GPR17 - 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, GPR14 e GPR15, que derivado do acompanhamento do dia-a-dia do projeto. Os marcos do projeto precisam, portanto, ser previamente definidos ao se realizar o planejamento do projeto. 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) O Plano do Projeto deve estabelecer os marcos e pontos de controle do projeto e que produtos devem ser revistos em cada um. A organizao adquirente responsvel pela reviso, nestes pontos, dos produtos cujo desenvolvimento est sob sua responsabilidade e dos produtos sob a responsabilidade do fornecedor. Sem comentrio adicional para este resultado.
5.3.18 GPR18 - 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 (GPR17) e de monitoramento (GPR13, GPR14 e GPR15) do projeto possibilitam a identificao de problemas que estejam
ocorrendo nos projetos. natural que problemas e desvios em relao ao planejamento aconteam durante a execuo dos projetos. Estes problemas e desvios devem ser analisados e registrados, por exemplo, por meio de ferramentas especficas, planilhas ou outros tipos de mecanismos de gerenciamento de problemas. A falha na execuo desta tarefa pode afetar a habilidade de executar aes para correo dos desvios, afetando o bom andamento do projeto. 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 (GPR19). Caso no se consiga resolver os problemas neste nvel, deve-se escalonar a resoluo das aes a nveis superiores de gerncia.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Deve ser registrado tanto o que teve origem na organizao adquirente quanto o que teve origem no fornecedor e foi identificado nas revises feitas pelo adquirente. Para as organizaes do tipo Fbrica de Software as dependncias crticas, em geral, tambm esto associadas ao relacionamento com a contratante, que a organizao responsvel por prover as especificaes. Sem comentrio adicional para este resultado.
5.3.19 GPR19 - 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, GPR14 e GPR15) e das revises em marcos (GPR17), problemas so identificados, analisados e registrados (GPR18). 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. O controle dos problemas levantados, as aes tomadas, os responsveis pelas aes e os resultados devem ser registrados. Os problemas identificados, e devidamente registrados, provem a base para a tomada de aes corretivas. Quando apropriado, e quando o impacto e os riscos associados so identificados 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 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 frequncia, se ela j foi resolvida e atuar em possveis pendncias. 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 no projeto, como clientes e usurios.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Devem ficar, claramente, definidas as responsabilidades da organizao adquirente e do fornecedor na resoluo das aes corretivas. Para as organizaes do tipo Fbrica de Software os problemas identificados podem envolver as especificaes provenientes da contratante, o que pode implicar em replanejamento e at mesmo renegociao de contrato. Nestes casos, importante identificar quem ser o responsvel pela ao corretiva: a Fbrica de Software ou a contratante. Esta identificao pode variar conforme as caractersticas do projeto ou devido a condies contratuais de atuao junto contratante. Nestes casos, a definio da responsabilidade pela ao corretiva pode estar definida e registrada, por exemplo, no contrato ou no plano de projeto. Fbrica de Teste (Parte 10) Em organizaes do tipo Fbrica de Teste, a responsabilidade pela ao corretiva pode variar. recomendado que isto j esteja definido no plano de projeto ou no contrato. De qualquer forma, dever ser registrado na resoluo de problemas, quem o responsvel pelas aes corretivas, se os membros do projeto ou a contratante.
Gerncia de Requisitos (GRE)
6.1 Propsito O propsito do processo Gerncia de Requisitos gerenciar os requisitos do produto e dos 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 apoio 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) No so permitidas excluses de resultados deste processo. No so permitidas excluses de resultados deste processo. No so permitidas excluses de resultados deste processo.
6.2 Fundamentao terica Uma boa comunicao com os fornecedores de requisitos fundamental para assegurar um bom entendimento das necessidades do cliente e dos requisitos do projeto e, consequentemente, aumentar as chances de sucesso do projeto. Existem diversos assuntos ligados a requisitos que devem ser tratados com os fornecedores de requisitos, como por exemplo: definio de requisitos, aprovao de requisitos, solicitao de mudana nos requisitos, dentre outros. Segundo Dorfmann e Thayer [1990], requisito de software representa a capacidade requerida pelo usurio que deve ser encontrada ou possuda por um determinado produto ou componente de produto para resolver um problema ou alcanar um objetivo ou para satisfazer a um contrato, a um padro, a uma especificao ou a outros documentos formalmente impostos. A gerncia de requisitos envolve identificar os requisitos do produto e dos componentes do produto do projeto, bem como estabelecer e manter um acordo entre o cliente e a equipe de projeto sobre esses requisitos. Tambm objetivo da gerncia de requisitos controlar e tratar as mudanas nos requisitos ao longo do desenvolvimento.
30/48
Para apoiar o processo de mudana de requisito, fundamental definir e manter a rastreabilidade dos requisitos. Rastreabilidade o grau em que o 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, 1990]. Quando os requisitos so bem gerenciados, a rastreabilidade pode ser estabelecida, desde um requisito fonte, passando por todos os nveis de decomposio do produto 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 [SEI, 2010]. 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 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Gerenciar requisitos em organizaes que adquirem software envolve a gerncia de requisitos resultante de atividades que executa e monitorar o processo de gerncia de requisitos do fornecedor. Para as organizaes do tipo Fbrica de Software a gerncia de requisitos envolve gerenciar as modificaes nas especificaes provenientes da organizao contratante.
31/48
A gerncia de requisitos para a Fbrica de Teste deve ser entendida como a gerncia de requisitos de teste. As mudanas de requisitos no produto de software e que est sendo gerenciada por uma outra parte devem ser monitoradas para que os requisitos de teste estejam aderentes aos requisitos do produto.
6.3 Resultados esperados 6.3.1 GRE1 - O entendimento dos requisitos obtido junto aos fornecedores de requisitos O objetivo deste resultado garantir que os requisitos estejam claramente definidos a partir do entendimento dos requisitos realizado junto aos fornecedores de requisitos. Informaes sobre esses fornecedores podem ser identificadas no plano do projeto, bem como informaes sobre como ser a comunicao com eles. Essas comunicaes devem ser registradas formalmente em atas, e-mails, ferramentas de comunicao ou outros meios. Como comprovao do entendimento, os requisitos devem ser documentados. Esta documentao pode assumir diferentes formas de acordo com as necessidades da organizao, por exemplo, uma lista de requisitos, especificaes de casos de uso, especificaes de estrias, ou ainda detalhados conforme uma metodologia prpria da organizao. Aps a identificao dos requisitos do produto e dos componentes do produto do projeto, importante garantir que os requisitos propostos atendam s necessidades e expectativas do cliente e dos usurios. Aps a avaliao dos requisitos, um registro de aceite dos requisitos deve ser obtido pelos fornecedores de requisitos. Esse registro pode ser tratado como um marco do projeto a partir do qual mudanas nos requisitos devem ser tratadas formalmente para minimizar o impacto dessas mudanas no projeto em termos de escopo, estimativas e cronograma, bem como compromissos j estabelecidos. Sempre que forem aprovadas mudanas nos requisitos, deve-se obter novas aprovaes dos requisitos do projeto, se possvel, a partir de critrios estabelecidos.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Dependendo das caractersticas da aquisio, as atividades relacionadas a este resultado podem, no incio do projeto, ser realizadas pela organizao adquirente ou pelo fornecedor. De qualquer forma, ao se iniciar sua participao no projeto, importante que a organizao fornecedora realize atividades direcionadas a entender, avaliar e aceitar os requisitos.
32/48
Para as organizaes do tipo Fbrica de Software as atividades relacionadas a este resultado envolvem o entendimento e a aceitao das especificaes enviadas pela organizao contratante. As especificaes recebidas constituem, neste caso, os requisitos do projeto. Dependendo das caractersticas do projeto de teste, as atividades relacionadas a este resultado podem ter sido especificadas pelo adquirente quando da contratao da fbrica de teste. No entanto, a fbrica de teste responsvel por entender, avaliar e aceitar os requisitos, incluindo os requisitos especficos para teste.
6.3.2 GRE2 - Os requisitos so avaliados com base em critrios objetivos e um comprometimento da equipe tcnica com estes requisitos obtido A avaliao e aprovao por parte do cliente aps o entendimento dos requisitos por si s no suficiente para que os requisitos sejam refinados e refletidos em modelos de anlise e projeto para a codificao. A avaliao dos requisitos deve envolver, alm do cliente, tambm, a equipe tcnica2 da organizao, podendo ser realizada de diversas formas. Alm disso, um comprometimento formal da equipe tcnica com os requisitos deve ser obtido e registrado, por exemplo, na forma de ata de reunio, e-mail ou algum outro mecanismo. Em geral, aconselhvel que os requisitos sejam avaliados pela equipe tcnica antes de serem submetidos para aprovao pelo cliente para evitar retrabalho ou a apresentao de um documento sem qualidade tcnica adequada para o cliente. Os requisitos identificados podem ser avaliados com base em um conjunto de critrios objetivos, previamente estabelecidos. Alguns exemplos de critrios so: possuir identificao nica; estar claro e apropriadamente declarado; no ser ambguo; ser relevante; ser completo; estar consistente com os demais requisitos; ser implementvel, testvel e rastrevel [IEEE, 1998]. O uso de um checklist para apoiar esta atividade pode ser til, pois favorece a identificao dos problemas mais frequentes em relao especificao de requisitos. Nem todos os membros da equipe tcnica do projeto precisam efetivamente participar da avaliao dos requisitos com base em critrios estabelecidos. No entanto, importante que haja o comprometimento de todos para que diminua o risco de os requisitos no serem entendidos perfeitamente por todos ou no poderem ser tratados adequadamente durante as atividades subsequentes do projeto. Uma prtica que algumas organizaes tm realizado com o intuito de satisfazer este resultado a realizao de uma reunio de kick off na qual 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
A equipe tcnica compreende todos os envolvidos diretamente no desenvolvimento do produto, por exemplo, analistas de sistemas, desenvolvedores, projetistas, entre outros. MPS.BR Guia de Implementao Parte 1:2011 33/48
do projeto. Em alguns casos, essa reunio feita posteriormente. importante observar que mudanas de requisitos aprovados pelos fornecedores de requisitos podem afetar compromissos j estabelecidos pela equipe tcnica. Nestes casos, um novo comprometimento da equipe tcnica com os requisitos modificados deve ser obtido e registrado aps os requisitos modificados terem sido novamente aprovados junto aos fornecedores de requisitos.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Independentemente de quem foi responsvel pela identificao de requisitos (organizao adquirente ou fornecedor), toda a equipe tcnica envolvida no desenvolvimento do produto deve se comprometer com os requisitos. O comprometimento do representante do fornecedor suficiente para evidenciar o comprometimento de toda a sua equipe tcnica em uma avaliao MPS da organizao adquirente. Em qualquer circunstncia responsabilidade do adquirente definir os critrios objetivos para avaliao dos requisitos. Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Sem comentrio adicional para este resultado.
6.3.3 GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida Este resultado indica a necessidade de se estabelecer um mecanismo que permita rastrear a dependncia entre os requisitos e os produtos de trabalho. Ter definida a rastreabilidade facilita 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 descritas no cronograma. Ao longo do projeto, os requisitos assumem diferentes abstraes e denominaes. Por exemplo, podem estar descritos na forma de necessidades e restries do cliente, requisitos de cliente, requisitos funcionais e no funcionais, casos de uso, requisitos tcnicos, requisitos de produto, estrias etc. Os requisitos, dentro do ciclo de vida do projeto, so posteriormente derivados em elementos de anlise e projeto (design) e, ento, transformados em cdigo fonte para, ento, serem testados (preferencialmente com base em casos de testes especficos). Em geral, o detalhamento dos requisitos, a transformao em modelos, a codificao e o planejamento e a execuo de testes so planejados para garantir a correta execuo do projeto, possivelmente, tendo tarefas previstas para as aes citadas anteriormente em um Plano do Processo para o Projeto ou em um
cronograma, conforme previsto pelo processo Gerncia de Projetos (GPR). Dessa forma, a existncia de rastreabilidade horizontal e vertical, conforme prevista neste resultado esperado, pressupe que diferentes abstraes dos requisitos (por exemplo, requisitos de cliente ou casos de uso), documentos relacionados (por exemplo, cronogramas e casos de testes) e o cdigo fonte sejam rastreveis entre si. importante ressaltar que este resultado estabelece a criao de um sistema de rastreamento e que no necessariamente envolve a criao de uma matriz de rastreabilidade 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.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Em algumas situaes, dependendo do acordo estabelecido com o fornecedor, responsabilidade da organizao fornecedora estabelecer e manter a rastreabilidade bidirecional dos requisitos definidos e responsabilidade da organizao adquirente verificar a sua adequao. Em outras situaes, tambm dependendo do acordo, parte da responsabilidade de elaborao e manuteno da rastreabilidade da organizao adquirente e parte da organizao fornecedora. Em uma avaliao MPS, a organizao adquirente deve evidenciar que possui o documento de rastreabilidade para os projetos concludos e que realizou a sua avaliao para os projetos concludos e em andamento. Fbrica de Software (Parte 9) Para as organizaes do tipo Fbrica de Software a rastreabilidade bidirecional dos requisitos envolve a rastreabilidade das especificaes recebidas em relao aos produtos produzidos pela prpria Fbrica de Software (ex.: cdigo, planos de teste unitrio etc.). Neste caso, como a Fbrica de Software no tem acesso aos requisitos originais do cliente ou suas necessidades de negcio, no ter como manter a rastreabilidade destes itens com os demais produtos por ela produzidos. H casos em que a contratante impem Fbrica de Software o seu padro de gerenciamento da rastreabilidade e, nestes casos, este fato poder estar registrado no contrato ou no plano de projeto. A rastreabilidade bidirecional, neste caso, feita em relao aos produtos de trabalho que sero gerados pela fbrica de teste (por exemplo: requisitos de teste, casos de teste, plano de teste e componentes automatizados) e aos requisitos. O objetivo especificar um mecanismo para analisar o impacto nos testes, quando uma mudana nos requisitos ocorrer. H casos em que a contratante impem Fbrica de Teste o seu padro de gerenciamento da rastreabilidade e, nestes casos, este fato poder estar registrado no contrato ou no plano de projeto.
Em uma avaliao MA-MPS os documentos produzidos pelo processo de desenvolvimento (por exemplo: classe ou especificaes) no faro parte do escopo da Fbrica de Teste.
6.3.4 GRE4 - Revises em planos e produtos de trabalho do projeto so realizadas visando a 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 equivalente 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. Exemplos de revises com esse objetivo so revises de monitorao e controle do projeto e inspees baseadas em critrios explcitos para identificar inconsistncias entre os planos, atividades e produtos de trabalho com os requisitos e com mudanas nesses requisitos. Quando h mudanas nos 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 ou cronograma do projeto; e outros. As aes para correes das inconsistncias devem ser acompanhadas at que sejam resolvidas.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Ao longo do projeto responsabilidade da organizao adquirente e da organizao fornecedora realizarem revises visando garantir a consistncia entre os requisitos e os produtos de trabalho do projeto. A organizao adquirente pode delegar esta responsabilidade para o fornecedor mas, neste caso, deve verificar se a reviso foi realizada de forma adequada e as inconsistncias corrigidas. Sem comentrio adicional para este resultado.
36/48
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, requisitos podem ser retirados do projeto e/ou mudanas podem ser feitas nos requisitos j existentes. Ressalta-se que, devido s mudanas, os requisitos podem ter que ser revistos, conforme definido no GRE4. 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. importante destacar que o mecanismo de rastreabilidade bidirecional institudo um importante mecanismo para facilitar a anlise de impacto. Muitas vezes mudanas nos projetos acontecem em diferentes nveis de abstrao dos requisitos, no apenas nos requisitos de cliente. Por exemplo, mudanas em casos de uso ou que afetem prottipos de telas podem precisar ser gerenciadas utilizando um mecanismo mais formal de controle de mudana. Dessa forma, indicado que a organizao determine a aplicabilidade da gerncia de mudana, conforme descrito neste resultado esperado. importante ressaltar que em um projeto no obrigatrio que sempre ocorram mudanas nos requisitos estabelecidos. Porm, raro um projeto no ter mudanas. Tambm vale ressaltar que, em uma avaliao da implementao deste resultado esperado segundo o mtodo MA-MPS definido no Guia de Avaliao [SOFTEX, 2011b], evidncias da gerncia de mudanas de requisitos devem ser fornecidas pelo menos para um dos projetos avaliados.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Mudanas nos requisitos de um projeto, muitas vezes, tm como consequncia a necessidade de alteraes no acordo estabelecido entre adquirente e fornecedor. Esta reviso do acordo deve ser realizada, quando pertinente, tendo em conta a anlise de impacto realizada. Sem comentrio adicional para este resultado.
As mudanas nos requisitos de um projeto podem surgir de diversas fontes, principalmente quando se est desenvolvendo os testes paralelamente ao desenvolvimento do produto. Portanto, mecanismos para definir como as mudanas de requisitos sero gerenciadas e/ou repassadas para a Fbrica de Teste pelo adquirente devem ser estabelecidos e declarados. Em alguns casos, estas definies devem estar explicitadas em contrato.
37/48
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 resultados esperados. A capacidade do processo expressa o grau de refinamento e institucionalizao com que o processo executado na organizao/unidade organizacional. No MR-MPS, medida que a organizao/unidade organizacional evolui nos nveis de maturidade, um maior nvel de capacidade para desempenhar o processo deve ser atingido [SOFTEX, 2011a]. 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) [SOFTEX, 2011a]. 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 RAP10. Numa avaliao, segundo o MA-MPS [SOFTEX, 2011b], exigido, para se considerar um processo SATISFEITO no nvel G, que o atributo de processo AP 1.1 seja caracterizado como T (Totalmente implementado) e que o atributo de processo AP 2.1 seja caracterizado como T (Totalmente implementado) ou L (Largamente implementado). importante destacar que, a partir do nvel E, as exigncias so diferentes, conforme descrito no Guia de Avaliao [SOFTEX, 2011b]. A seguir, os atributos de processo AP 1.1 e AP 2.1, conforme aplicveis no nvel G, so descritos com detalhes.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) No h nenhuma alterao nos resultados esperados para os atributos de processo pelo fato de tratar-se de uma organizao que adquire software. Todavia, estes resultados devero ser interpretados no contexto dos processos definidos para esta situao. No so permitidas excluses de resultados de atributos de processo. Fbrica de Software (Parte 9) No h nenhuma alterao nos resultados esperados para os atributos de processo pelo fato de tratar-se de uma organizao do tipo Fbrica de Software. Todavia, estes resultados devero ser interpretados no contexto dos processos definidos para a Fbrica de Software. No so permitidas excluses de resultados de atributos de processo. Fbrica de Teste (Parte 10) No h nenhuma alterao nos resultados esperados para os atributos de processo pelo fato de tratar-se de uma organizao do tipo Fbrica de Teste. Todavia, estes resultados devero ser interpretados no contexto dos processos definidos para a Fbrica de Teste. No so permitidas excluses de resultados de atributos de processo.
38/48
7.1 AP 1.1 - O processo executado Este atributo evidencia o 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 evidencia o 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 de uma poltica contendo as diretrizes de como a organizao planeja e implementa os seus processos, bem como informaes sobre as expectativas organizacionais para a execuo dos processos e a indicao de como devem ser atendidos os aspectos mais importantes de cada processo. Isso pode incluir princpios bsicos e definies gerais de como executar os processos, 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. Um documento genrico pode existir definindo quem tem autoridade, delegada pela gerncia de alto nvel, para aprovar cada tipo de documento. Normalmente, as polticas so definidas e aprovadas pela gerncia de alto nvel, no havendo a obrigatoriedade de serem rotuladas exatamente de polticas. Uma vez definidas, as polticas devem ser publicadas e divulgadas aos interessados em sua execuo. Tal publicao pode ser realizada, por exemplo, na Intranet da organizao. Em geral, a divulgao da poltica pela alta gerncia ajuda a enfatizar a importncia dos processos, facilitando sua institucionalizao.
39/48
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, porm no se restringindo a ela.. importante que o planejamento seja revisto, sempre que necessrio, especialmente quando forem aprovadas mudanas significativas. 7.2.3 RAP4 - (Para o nvel G) A execuo do processo monitorada e ajustes so realizados 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, quando aplicvel. 7.2.4 RAP5 - As informaes e os recursos necessrios para a execuo do processo so identificados e disponibilizados Um aspecto crtico da implementao de um processo garantir que as condies necessrias para ter sucesso na implementao do processo definido esto presentes. Este resultado visa assegurar que as informaes e 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). Estas informaes e recursos podem estar estabelecidos na prpria descrio do processo ou podem, tambm, estar presentes em planos especficos para os processos nos nveis da organizao e/ou projeto. 7.2.5 RAP6 - (At o nvel F) As responsabilidades e a autoridade para executar o processo so definidas, atribudas e comunicadas Este resultado visa assegurar que as responsabilidades e a autoridade para executar o processo esto claramente definidas e bem compreendidas. Deve-se assegurar, tambm, que as responsabilidades e a autoridade para executar o processo foram atribudas explicitamente e comunicadas a todas as partes interessadas, por exemplo, patrocinador, implementadores etc.
40/48
7.2.6 RAP7 - As pessoas que executam o processo so competentes em termos de formao, treinamento e experincia Este resultado visa assegurar que as pessoas alocadas tenham as habilidades, conhecimentos e experincias 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 se restringem aos documentos de processo, mas podem incluir trabalho em grupo, liderana, anlise e soluo de problemas. Quando se julgar necessrio, um treinamento apropriado deve ser fornecido para as pessoas que executaro os processos. Os treinamentos podem ser de diferentes tipos, por exemplo: treinamento autodirecionado; instruo programada autodefinida; treinamento formal dentro do trabalho; mentoring; 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.7 RAP8 - A comunicao entre as partes interessadas no processo planejada e executada de forma a garantir o seu envolvimento O objetivo deste resultado identificar as partes interessadas no processo, planejar, executar 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.8 RAP9 - (At o nvel F) Os resultados do processo so revistos com a gerncia de alto nvel para fornecer visibilidade sobre a sua situao na organizao O objetivo deste resultado fornecer visibilidade alta gerencia com relao ao estado da execuo dos processos, considerando sua adequao, operao com recursos apropriados e alcance dos resultados esperados. 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, ento, 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. Este resultado no deve ser confundido com a monitorao do processo conforme definida no RAP4, mas pode utilizar tambm os dados obtidos a partir de sua execuo.
41/48
7.2.9 RAP10 - (Para o nvel G) O processo planejado para o projeto executado O objetivo deste resultado garantir que o projeto conduzido a partir da execuo do seu processo planejado. Deve-se garantir que existem registros de execuo das atividades do processo com base no seu planejamento. Esses registros devem ser mantidos e revistos periodicamente para garantir que o processo planejado est sendo seguido para atingir os objetivos do projeto.
42/48
Referncias bibliogrficas [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. [HOFMANN et al., 2007] HOFMANN, H. F., YEDLIN, D. K., MISHLER, J. W., KUSHNER, S., 2007, CMMI for Outsourcing, Addison Wesley, 2007. [IEEE, 1990] Std 610.12 - IEEE Standard Glossary of Software Engineering Terminology, Institute of Electrical and Electronics Engineers, 1990. [IEEE, 1998] Std 830-1998 - IEEE recommended practice for software requirements specifications, Institute of Electrical and Electronics Engineers, 1998. [ISO/IEC, 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. [ISO/IEC, 2003] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-2: Information Technology - Process Assessment Part 2 - Performing an Assessment, Genebra: ISO, 2003. [ISO/IEC, 2008] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 12207:2008 Systems and software engineering Software life cycle processes, Geneve: ISO, 2008. [KRUCHTEN, 2003] KRUCHTEN, P., The Rational Unified Process: An Introduction, 3a Edio, Addison-Wesley Object Technology Series, 2003. [PMI, 2008] PROJECT MANAGEMENT INSTITUTE. A Guide To The Project Management Body of Knowledge. 4. ed. Newton Square: PMI Publications, 2008PROJECT MANAGEMENT INSTITUTE PMI. A Guide to the Project Management Body of Knowledge - PMBOK, Syba: PMI Publishing Division, 2004. Disponvel em: <www.pmi.org>. [SEI, 20102010] SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV), Version 1.3, Technical Report CMU/SEI-2010-TR-033. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2010. [SOFTEX, 2011a] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral:2011, junho 2011. Disponvel em www.softex.br [SOFTEX, 2011b] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Avaliao:2011, maio 2011. Disponvel em www.softex.br [SOFTEX, 2011c] - ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Aquisio:2011, junho 2011. Disponvel em www.softex.br
[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.
44/48
Lista de colaboradores do Guia de Implementao Parte 1:2011
Editores: Gleison dos Santos Souza Ana Regina C. Rocha Revisores: Ana Liddy Cenni C. Magalhes Danilo Scalet Reinaldo Cabral Silva Filho QualityFocus e UFMG CELEPAR COPPE/UFRJ e UFAL COPPE/UFRJ COPPE/UFRJ (Coordenadora da ETM)
45/48
Lista de colaboradores do Guia de Implementao Parte 1:2009
Editores: Ana Regina C. Rocha Gleison dos Santos Souza Mariano Angel Montoni Revisores: Ana Ceclia Peixoto Zabeu Ana Liddy C. C. Magalhes Ana Regina C. Rocha Carla Alessandra Lima Reis Danilo Scalet Edmeia Leonor Pereira de Andrade ASR QualityFocus e Universidade FUMEC COPPE/UFRJ (Coordenadora da ETM) QR e UFPA CELEPAR EMBRAPA e UCB COPPE/UFRJ (Coordenadora da ETM) COPPE/UFRJ COPPE/UFRJ
46/48
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 Edmeia Leonor Pereira de Andrade CELEPAR MAPA COPPE/UFRJ COPPE/UFRJ (Coordenadora da ETM) SwQuality
47/48
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
48/48

Guia de Implementacao Parte 1 2011

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Guia de Implementacao Parte 1 2011

Загружено:

Авторское право:

Доступные форматы

MPS.

BR - Melhoria de Processo do Software Brasileiro

Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS

MPS.BR Guia de Implementao Parte 1:2011

As alteraes deste Guia de Implementao em relao verso 2009 so decorrentes de:

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Software (Parte 9)

Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Software (Parte 9)

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Software (Parte 9)

Fbrica de Teste (Parte 10)

Fbrica de Software (Parte 9)

Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Teste (Parte 10)

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Software (Parte 9)

Fbrica de Teste (Parte 10)

Fbrica de Software (Parte 9)

Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Teste (Parte 10)

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

Fbrica de Teste (Parte 10)

Gerncia de Requisitos (GRE)

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Software (Parte 9)

Fbrica de Teste (Parte 10)

Fbrica de Teste (Parte 10)

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 1:2011

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 1:2011

Os atributos de processo no nvel G

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

Lista de colaboradores do Guia de Implementao Parte 1:2011

MPS.BR Guia de Implementao Parte 1:2011

Lista de colaboradores do Guia de Implementao Parte 1:2009

MPS.BR Guia de Implementao Parte 1:2011