Você está na página 1de 96

MPS.

BR - Melhoria de Processo do Software Brasileiro

Guia de Aquisio

Este guia descreve um processo de aquisio de software e servios correlatos, baseado na Norma Internacional ISO/IEC 12207:2008.

Outubro 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-32-4

Sumrio
1 2 3 4 4.1 4.2 4.3 4.4 4.5 Prefcio .............................................................................................................. 4 Introduo .......................................................................................................... 6 Objetivo .............................................................................................................. 7 Descrio do processo de aquisio ................................................................. 8 Viso geral ......................................................................................................... 8 Preparao da aquisio ................................................................................... 9 Seleo do fornecedor..................................................................................... 15 Monitorao do contrato .................................................................................. 19 Aceitao pelo cliente ...................................................................................... 25

Anexo A Plano de aquisio.................................................................................... 31 Anexo B - Pedido de proposta.................................................................................... 39 Anexo C - Proposta dos fornecedores ....................................................................... 41 Anexo D - Contrato ..................................................................................................... 43 Anexo E Registro de revises ................................................................................. 47 Anexo F Aspectos relevantes na aquisio de S&SC ............................................ 49 F.1 Viso geral............................................................................................................ 49 F.2 Problemas comuns na aquisio ......................................................................... 49 F.3 Aquisio de software livre/cdigo aberto (SL/CA).............................................. 53 F.4 Aquisio e a Engenharia de Software baseada em componentes .................... 55 Anexo G - Funes no projeto de aquisio .............................................................. 58 G.1 Viso geral ........................................................................................................... 58 G.2 Funes do patrocinador ..................................................................................... 59 G.3 Funes de gesto .............................................................................................. 59 G.4 Funes de assistncia ou suporte ..................................................................... 60 G.5 Funes executivas ............................................................................................. 62 Anexo H - Normas brasileiras e ISO/IEC para avaliao de produto de software .... 64 H.1 Descrio geral .................................................................................................... 64 H.2 Avaliao utilizando a ABNT NBR ISO/IEC 25051 ............................................. 64 H.3 Avaliao com as sries ABNT NBR ISO/IEC 9126 e 14598 ............................ 65 H.4 A srie de normas SQuaRE ................................................................................ 68 Anexo I Processos de aquisio da ISO/IEC 12207 e IEEE STD 1062:1998 ........ 73

MPS.BR-Guia de Aquisio:2011

2/96

I.1 Processo da ISO/IEC 12207 ................................................................................. 73 I.2 Processo da IEEE STD 1062:1998 ....................................................................... 74 Anexo J Habilitao de consultores de aquisio MPS .......................................... 79 J.1 Habilitao de consultores de aquisio. ............................................................. 79 Anexo K Iniciativas de utilizao de processos de aquisio na rea pblica ....... 80 K.1 Personalizao de processo de aquisio .......................................................... 80 K.2 Personalizao de processo de aquisio para organizaes pblicas ............. 81 Referncias bibliogrficas .......................................................................................... 87 Lista de colaboradores do Guia de Aquisio:2011................................................... 92 Lista de colaboradores do Guia de Aquisio:2009................................................... 93 Lista de colaboradores do Guia de Aquisio verso 1.2 .......................................... 94 Lista de colaboradores do Guia de Aquisio verso 1.1 .......................................... 95 Lista de colaboradores do Guia de Aquisio verso 1.0 .......................................... 96

MPS.BR-Guia de Aquisio:2011

3/96

1 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 e Instituies de Consultoria de Aquisio (ICA) credenciadas 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 Aquisio:2011

4/96

A criao e o aprimoramento deste Guia de Aquisio so tambm atribuies da ETM, sendo que este guia faz parte do seguinte conjunto de documentos do modelo MPS: Guia Geral:2011 [SOFTEX, 2011a]; Guia de Avaliao:2011 [SOFTEX, 2011b]; Guia de Aquisio:2011; Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS:2011 [SOFTEX, 2011c]; Guia de Implementao Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS:2011 [SOFTEX, 2011d]; Guia de Implementao Parte 3: Fundamentao para Implementao do Nvel E do MR-MPS:2011 [SOFTEX, 2011e]; Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS:2011 [SOFTEX, 2011f]; Guia de Implementao Parte 5: Fundamentao para Implementao do Nvel C do MR-MPS:2011 [SOFTEX, 2011g]; Guia de Implementao Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS:2011 [SOFTEX, 2011h]; Guia de Implementao Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS:2011 [SOFTEX, 2011i]; Guia de Implementao Parte 8: Implementao do MR-MPS:2011 (Nveis G a A) em organizaes que adquirem software [SOFTEX, 2011j]; Guia de Implementao Parte 9: Implementao do MR-MPS:2011 (Nveis G a A) em organizaes do tipo Fbrica de Software [SOFTEX, 2011k]; e Guia de Implementao Parte 10: Implementao do MR-MPS:2011 (Nveis G a A) em organizaes do tipo Fbrica de Teste SOFTEX, 2011m; Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS (Nveis G a A) em conjunto com o CMMI-DEV[SOFTEX, 2011m].

Este Guia de Aquisio tem como referncia o Processo de Aquisio da Norma Internacional ISO/IEC 12207:2008. A norma IEEE STD 1062:1998 pode ser utilizada para complementar e detalhar as atividades do processo de aquisio.. A verso 2009 deste Guia de Aquisio compatibilizou o processo de aquisio com a verso 2008 da norma ISO/IEC 12207 e atualizou o contedo referente s normas de qualidade de produto de software, ajustando-o s normas j publicadas da srie ISO/IEC 25000 e correspondentes normas brasileiras. Alm disso, o escopo do documento ficou delimitado especificamente como um guia de orientao a organizaes que pretendam conduzir projetos de aquisio, evidenciando que no trata da preparao destas organizaes para serem avaliadas quanto a nveis de maturidade. Neste sentido, as referncias especficas aos processos e nveis de capacidade abordadas no Guia Geral foram excludas do Guia de Aquisio.

MPS.BR-Guia de Aquisio:2011

5/96

A verso 2011 deste Guia de Aquisio atualizou a situao das normas da srie ISO/IEC 25000, alm de incluir o anexo K que aborda iniciativas de uso de processo de aquisio para organizaes pblicas. 2 Introduo O MPS.BR tem como foco, ainda que no exclusivo, atender a micro, pequenas e mdias empresas de software brasileiras, com poucos recursos e que desejem obter melhorias significativas nos seus processos de software. Busca-se que o modelo MPS seja adequado ao perfil de empresas com diferentes tamanhos e caractersticas, pblicas e privadas, 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, o modelo MPS tem como base os requisitos de processos definidos nos modelos de melhoria de processo e busca atender a necessidade de implantar os princpios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras, estando em consonncia com as principais abordagens internacionais para definio, avaliao e melhoria de processos de software. A introduo da aquisio de S&SC como parte do MPS.BR tem como finalidade orientar as organizaes que adquirem S&SC, por meio de um processo de aquisio onde so descritas as atividades e tarefas fundamentais para a garantia da qualidade do contrato e respectivos produtos e servios entregues pelo fornecedor. Este guia ser tambm um importante elemento indutor de melhorias de processos de organizaes fornecedoras, contribuindo como um documento orientador a ser usado para atender s necessidades e requisitos dos clientes, conforme definido no plano de aquisio e respectivo contrato. A aquisio de S&SC um processo complexo, principalmente no que diz respeito caracterizao dos requisitos necessrios ao S&SC e s condies envolvidas na contratao como, por exemplo, qualidade esperada, forma de aceitao, gesto de mudanas, artefatos2 esperados, entre outros. Este ambiente apresenta riscos para as partes envolvidas e, como consequncia, comum a ocorrncia de srios conflitos na relao entre fornecedores e adquirentes de software. Diante deste cenrio, foram empreendidas vrias iniciativas internacionais com vistas a tornar este processo mais previsvel e com melhores resultados para os envolvidos, resultando, como consequncia, desde padres especficos para grandes organizaes compradoras de software, at normas internacionais que visam orientar relaes tcnicas e comerciais. A elaborao do Guia de Aquisio levou em conta documentos resultantes destes trabalhos, alm de considerar relacionamentos do processo de aquisio com aspectos definidos pelo MR-MPS.

Qualquer parte tangvel de informao que criada, alterada e utilizada pelo projetista durante o processo de desenvolvimento de software. De acordo com esta definio, um artefato de software pode ser um documento de especificao de requisitos, arquitetura, programa, partes de programa, projeto, modelo, ou qualquer outro documento associado ao software.

MPS.BR-Guia de Aquisio:2011

6/96

Como a implementao do MR-MPS est relacionada aos processos da norma ISO/IEC 12207, o Guia de Aquisio, tambm est baseado no processo de aquisio daquela Norma Internacional, adotando como base os processos de nvel inferior (decomposio do processo de aquisio em processos mais detalhados) do processo de aquisio, conforme consta no anexo B da norma ISO/IEC 12207. O Guia de Aquisio fornece informaes complementares norma ISO/IEC 12207, identificando o relacionamento entre os processos desta norma e da IEEE STD 1062:1998. 3 Objetivo Este documento descreve um processo de aquisio de S&SC baseado na Norma Internacional ISO/IEC 12207:2008, complementado pela norma IEEE STD 1062:1998. A organizao deste documento visa servir como um guia para empresas que adquirem S&SC, detalhando as atividades e tarefas envolvidas, descrevendo os produtos de trabalho e fornecendo exemplos de preenchimento dos principais documentos. Observe-se que no objetivo deste guia servir como Guia de Implementao para um processo de aquisio que venha a ser avaliado utilizando-se o MA-MPS, pois este o propsito de outros guias do modelo MPS. No contexto de aquisio de S&SC considera-se o produto de software propriamente dito, alm de servios tipicamente relacionados ao desenvolvimento, implantao, suporte operao e manuteno do software, tais como treinamento, configurao do software e do ambiente de operao, manutenes corretivas, evolutivas e adaptativas, entre outros. O processo descrito no Guia de Aquisio perfeitamente ajustado para aquisies de produtos de prateleira comercialmente disponveis (pacote de software), de produtos de software personalizados ou de um domnio especfico, tanto por instituies privadas como por instituies pblicas. No caso de instituies pblicas deve ser considerada a legislao que regulamenta as aquisies, de acordo com as diferentes modalidades de licitao estabelecidas. No caso de contrataes de escopo aberto, que englobam servios de desenvolvimento de software, necessrio que o processo seja personalizado, principalmente para contemplar a eventual inexistncia de requisitos especficos para os produtos a serem desenvolvidos, quando do processo de contratao. Deste modo, o processo dever trabalhar com requisitos gerais a serem considerados para todos os produtos de software que vierem a ser desenvolvidos ao longo do contrato a ser firmado entre as partes. Alm disso, como o processo pressupe tarefas planejadas e resultados contratados e avaliados, a modalidade de contratao de mo de obra est fora do escopo deste guia. O processo de aquisio est descrito na seo 4, onde esto detalhadas as atividades e as suas tarefas, bem como os respectivos produtos requeridos, e produtos gerados. Os Anexos de A at E apresentam sugestes de modelos de documentos que podem ser utilizados e personalizados pelas organizaes compradoras. O Anexo F aborda alguns aspectos importantes a serem considerados na aquisio de S&SC, tais como problemas que so enfrentados, software livre/cdigo aberto e Engenharia de Software baseada em componentes. O Anexo G aponta possveis funes envolvidas em processos de aquisio. O Anexo H apresenta um conjunto de normas que podem ser utilizadas na avaliao de produto de software durante o processo de aquisio. O Anexo I apresenta uma breve

MPS.BR-Guia de Aquisio:2011

7/96

descrio dos processos definidos nas normas internacionais ISO/IEC 12207 e IEEE STD 1062:1998, bem como um mapeamento de seus relacionamentos. O Anexo J descreve como os profissionais devem proceder para serem certificados como Consultores de Aquisio MPS.BR, qual a qualificao profissional e acadmica desejada para essa certificao , alm dos requisitos de treinamento, avaliao e elaborao de um Plano de Aquisio de Software. Finalmente o Anexo K identifica algumas iniciativas que vm sendo adotadas no Brasil personalizando um processo de aquisio de S&SC para organizaes pblicas. Este documento destinado, mas no est limitado, a instituies interessadas em aquisio de S&SC. Destina-se tambm, como uma referncia, a instituies desenvolvedoras de software que pretendam preparar-se para participar de processos de seleo em conformidade com o estabelecido neste guia. 4 Descrio do processo de aquisio 4.1 Viso geral O propsito do processo de aquisio obter S&SC que satisfaam a necessidade expressa pelo cliente. Este processo inicia com a identificao da necessidade do cliente e encerra com a aceitao do produto ou servio. Como resultado da implementao bem-sucedida do processo de aquisio: 1. as necessidades de aquisio, as metas, os critrios de aceitao do S&SC e as estratgias de aquisio so definidos; 2. um contrato que expresse claramente a expectativa, as responsabilidades e as obrigaes de ambos (cliente e fornecedor) elaborado; 3. um ou mais fornecedores so selecionados; 4. S&SC que satisfaam a necessidade expressa pelo cliente so adquiridos; 5. a aquisio monitorada de forma que as condies especificadas sejam atendidas, tais como: custo, cronograma e qualidade; 6. os produtos e servios entregues pelo fornecedor so aceitos; e 7. qualquer pendncia identificada tem uma concluso satisfatria, conforme acordado entre o cliente e o fornecedor. Este processo ser descrito a seguir pelas suas 4 (quatro) atividades (Figura 1): Preparao da aquisio (ver 4.2) Seleo do fornecedor (ver 4.3) Monitorao do contrato (ver 4.4) Aceitao pelo cliente (ver 4.5)

MPS.BR-Guia de Aquisio:2011

8/96

Preparao da aquisio Seleo do fornecedor Monitorao do contrato

1. 2. 3. 4. 5. 1. 2. 3. 1. 2. 3. 4. 5. 6. 1. 2. 3. 4.

Estabelecer a necessidade Definir os requisitos Revisar os requisitos Desenvolver uma estratgia de aquisio Definir os critrios de seleo de fornecedores Avaliar a capacidade dos fornecedores Selecionar o fornecedor Preparar e negociar um contrato Estabelecer e manter comunicaes Trocar informao sobre o progresso tcnico Revisar o desempenho do fornecedor Monitorar a aquisio Obter acordo quanto s alteraes Acompanhar problemas Preparar a aceitao Avaliar o S&SC entregue Manter conformidade com o contrato Aceitar o S&SC

Aceitao pelo cliente

Figura 1 Atividades de aquisio Cada uma das atividades est detalhada pelos seguintes itens: Objetivo: descreve os objetivos a serem alcanados com a realizao da atividade e prov orientaes gerais; Tarefas previstas: identifica e descreve as tarefas necessrias para atingir os objetivos e obter os resultados previstos para a atividade; e Produtos requeridos e gerados: relaciona os insumos necessrios para executar cada tarefa prevista na atividade, bem como os produtos das tarefas previstas na atividade. Para alguns destes produtos h referncias de modelos descritos nos anexos de A at E deste guia.

4.2 Preparao da aquisio 4.2.1 Objetivo O propsito da atividade de preparao da aquisio estabelecer as necessidades e os requisitos da aquisio e comunic-los aos potenciais fornecedores. A execuo desta atividade fundamental para o estabelecimento da estratgia de conduo de todo o processo de aquisio, levando-se em conta as necessidades e requisitos estabelecidos, bem como as demais variveis de contexto da aquisio. As tarefas previstas compreendem: Estabelecer a necessidade (ver Pre-t1); Definir os requisitos (ver Pre-t2); Revisar requisitos (ver Pre-t3);

MPS.BR-Guia de Aquisio:2011

9/96

Desenvolver uma estratgia de aquisio (ver Pre-t4); e Definir os critrios de seleo de fornecedores (ver Pre-t5). 4.2.2 Tarefas previstas Id. Pre-t1 Tarefa Estabelecer a necessidade
Descrio:

Estabelecer as necessidades a serem atendidas por meio da aquisio, desenvolvimento ou melhoria de um sistema, produto de software ou servio de software. Durante esta tarefa so analisadas as necessidades e resultados que a organizao pretende atingir com o projeto de aquisio, avaliando-se o efetivo escopo das necessidades a serem contempladas pela aquisio. Esta tarefa fundamental, pois indica a primeira tomada de deciso quanto ao prosseguimento do projeto e que resultados so esperados pela organizao aps a efetivao da aquisio.
Produtos requeridos:

Pre-p1 - Avaliao da necessidade do S&SC


NOTA: Eventualmente este trabalho de avaliao da necessidade complementado no prprio processo de aquisio, medida que em alguns casos so apenas esboadas as necessidades pela organizao adquirente. Produtos gerados:

Pre-p2 - Resultado da anlise da necessidade da aquisio


NOTA: A tarefa define, neste documento, o conjunto de necessidades a serem contempladas pelo sistema, produto de software ou servio de software.

Pre-t2

Definir os requisitos
Descrio:

Identificar os requisitos do cliente para um S&SC. Se necessrio, as organizaes podero solicitar informaes de fornecedores ou realizar pesquisas e identificar as melhores prticas de outras organizaes, que adquiriram produtos e servios semelhantes, com vistas a determinar os requisitos a partir de solues disponveis no mercado. Durante esta tarefa devem ser especificados os requisitos a serem considerados no projeto de aquisio, incluindo os seguintes: dos interessados (stakeholders): as necessidades devem ser transformadas em requisitos mais especficos que contemplem os diversos tipos de interessados (stakeholders), tais como, usurios, planejadores, gestores, desenvolvedores e beneficirios do sistema;

MPS.BR-Guia de Aquisio:2011

10/96

do sistema: requisitos envolvendo processos, hardware, software, integraes, ambiente e pessoas que iro compor a soluo que atender as necessidades estabelecidas; do software: requisitos do(s) produto(s) de software que ir(o) compor o(s) sistema(s) a ser(em) implementado(s). Devem ser especificados os requisitos funcionais e requisitos de qualidade; de projeto: ciclo de vida a ser adotado, tcnicas, metodologias, forma de gesto e de documentao do projeto; de manuteno: requisitos relacionados manuteno do software aps a sua entrega; de treinamento: caractersticas esperadas do treinamento relacionado ao S&SC a serem entregues; e de implantao: descrio dos procedimentos necessrios para a implantao do software no ambiente de operao, como, por exemplo, a carga do banco de dados, a implementao numa configurao distribuda, entre outros.

Alm destes requisitos, podem ser considerados outros requisitos e restries que afetam diretamente o projeto de aquisio como, por exemplo, restries legais, financeiras, de prazo do projeto e de nmero de usurios do sistema em operao. O adquirente poder definir e analisar os requisitos com sua prpria equipe ou contratar um fornecedor para executar estas atividades. Neste caso, o adquirente dever manter a responsabilidade pela aprovao do resultado da anlise dos requisitos.
Produtos requeridos:

Pre-p2 - Resultado da anlise da necessidade da aquisio Pre-p3 - Relatrio da anlise de mercado


NOTA: Este documento , em geral, elaborado como parte do processo de anlise de viabilidade de iniciar o projeto de aquisio, avaliando-se o problema da organizao e as alternativas possveis de soluo que o mercado oferece. Produtos gerados:

Pre-p2 - Resultado da anlise da necessidade da aquisio revisado


NOTA: Esta tarefa pode causar a reviso do escopo das necessidades a serem atendidas em funo das caractersticas dos requisitos a serem contemplados para atender as necessidades, que podem causar impactos em custo e prazo.

Pre-p4 - Especificao de requisitos

MPS.BR-Guia de Aquisio:2011

11/96

Pre-t3

Revisar os requisitos
Descrio:

Analisar e validar os requisitos definidos com relao s necessidades da aquisio, para reduzir os riscos de no entendimento por parte dos potenciais fornecedores. A reviso dos requisitos estabelecidos deve considerar itens como: Avaliar se todos os interessados (stakeholders) esto sendo considerados nos requisitos, ou se as ausncias so justificadas; Verificar eventuais situaes inconsistncias entre requisitos; Verificar a existncia de ambguos e no verificveis; de conflitos e

requisitos

incompletos,

Verificar se os requisitos do software contemplam aspectos funcionais e de qualidade; Avaliar a relao entre custo e benefcio dos requisitos, apontando situaes crticas.

Produtos requeridos:

Pre-p2 - Resultado da anlise da necessidade da aquisio Pre-p4 - Especificao de requisitos


Produtos gerados:

Pre-p4 - Especificao de requisitos revisada Pre-p5 - Registro da reviso dos requisitos Pre-t4 Desenvolver uma estratgia de aquisio
Descrio:

Desenvolver uma estratgia para a aquisio do S&SC compatvel com as necessidades a serem atendidas pela aquisio. O adquirente deve considerar opes viveis para a aquisio, analisando critrios que levem em conta riscos, custos e benefcios de cada opo. Deve-se considerar opes como: Comprar um produto de software comercial de prateleira que satisfaa aos requisitos; Desenvolver o produto de software ou obter o servio de software internamente organizao; Desenvolver o produto de software ou obter o servio de software por meio de um contrato; Realizar uma combinao dos trs itens anteriores; Aprimorar um produto ou servio de software existente.

MPS.BR-Guia de Aquisio:2011

12/96

Esta tarefa responsvel por orientar a conduo das tarefas das demais atividades de aquisio, levando em conta as necessidades e requisitos estabelecidos e os contextos da organizao adquirente e do mercado fornecedor. A representao da estratgia se materializa por meio do plano de aquisio, que insumo para elaborao do pedido de proposta e contempla itens como: os termos contratuais, os termos financeiros, os termos tcnicos, a lista de produtos e servios a serem fornecidos, os mecanismos de controle do projeto de aquisio, normas e modelos a serem seguidos pelo fornecedor, riscos identificados no projeto, critrios de aceitao do produto e servios e as responsabilidades das organizaes envolvidas no projeto.
Produtos requeridos:

Pre-p2 - Resultado da anlise da necessidade da aquisio revisado Pre-p3 - Relatrio da anlise de mercado Pre-p4 - Especificao de requisitos revisada
Produtos gerados:

Pre-p6 - Plano de aquisio Pre-p7 - Plano de teste do S&SC para sua aceitao
NOTA: Viso inicial do plano de testes obtida a partir da estratgia de definio e dos critrios de aceitao. Os critrios de aceitao definem os aspectos que devem ser satisfeitos para que o S&SC sejam aceitos.

Pre-p8 - Pedido de proposta Pre-t5 Definir os critrios de seleo de fornecedores


Descrio:

Estabelecer e acordar os critrios de seleo de fornecedores, bem como a forma de avaliao a ser aplicada. Como fatores que podem influenciar na escolha do fornecedor podem ser citados: localizao geogrfica do fornecedor; registro de desempenho em trabalhos similares; equipe e infra-estrutura disponveis para o desenvolvimento do produto desejado; tempo de mercado; experincia no domnio do problema; nvel de qualidade de seus processos utilizados; e certificaes exigidas.
Produtos requeridos:

Pre-p3 - Relatrio da anlise de mercado Pre-p4 - Especificao de requisitos revisada Pre-p6 - Plano de aquisio Pre-p8 - Pedido de proposta
Produtos gerados:

Pre-p6 - Plano de aquisio

MPS.BR-Guia de Aquisio:2011

13/96

NOTA: Incluindo os critrios de seleo de fornecedores.

Pre-p8 - Pedido de proposta


NOTA: Incluindo os critrios de seleo de fornecedores.

4.2.3 Produtos requeridos e gerados Id. Pre-p1 Produtos Descrio

Avaliao da necessidade do Documento contendo a necessidade do S&SC S&SC e alinhamento da aquisio aos objetivos da organizao. Descrio dos objetivos que se pretende atingir com a aquisio. Resultado da anlise da Documento que detalhe os critrios e necessidade da aquisio resultados obtidos durante a anlise que definiu as necessidades e requisitos para o S&SC a ser adquirido. O resultado principal deste documento a definio do escopo das necessidades e requisitos a serem contemplados no projeto de aquisio. Relatrio mercado da anlise de Documento contendo as alternativas que o mercado oferece com relao ao S&SC desejado, com suas respectivas vantagens e desvantagens. Este documento fornece, organizao adquirente, uma referncia para a elaborao dos requisitos do S&SC desejado. Documento que define os requisitos e restries definidas pelo cliente, incluindo requisitos dos interessados (stakeholders), do sistema (quando for o caso), do software, de projeto, de manuteno, de treinamento e de implantao, restries legais, financeiras, de prazo e de nmero de usurios.

Pre-p2

Pre-p3

Pre-p4

Especificao de requisitos

Pre-p5

Registro da requisitos

reviso

dos Documento que registre os resultados do processo utilizado para reviso dos requisitos especificados como, por exemplo, relao dos interessados (stakeholders) que participaram da reviso, problemas identificados e como eles foram sanados, alm da aprovao, quando pertinente. Documento que define os objetivos especficos a serem alcanados com a

Pre-p6

Plano de aquisio

MPS.BR-Guia de Aquisio:2011

14/96

(ver anexo A)

aquisio, os riscos envolvidos e um plano de projeto, contemplando itens como: prazos, custos, requisitos e restries, critrios de seleo de fornecedores, produtos e servios a serem fornecidos, critrios de aceitao do S&SC, responsabilidades das organizaes envolvidas na aquisio, riscos envolvidos e mecanismos de controle (como os produtos gerados e os processos utilizados pelo fornecedor sero monitorados).

Pre-p7

Plano de teste do S&SC para Documento que define as condies, sua aceitao tarefas e responsabilidades pela execuo dos testes necessrios para a aceitao do S&SC a ser adquirido. Para a elaborao deste documento deve-se levar em conta os requisitos desejados para o S&SC, bem como os critrios estabelecidos para a aceitao. Este documento de orientao ser atualizado e detalhado medida que sejam especificadas as funes do software ao longo da execuo do contrato. Pedido de proposta (ver anexo B) Documento que caracteriza o S&SC requerido e as condies de entrega, alm das condies gerais esperadas da aquisio, prazos e valores envolvidos, critrios de seleo de fornecedores, critrios de aceitao do S&SC e outras questes formais a serem seguidas. O pedido de proposta deve estar alinhado ao plano de aquisio. Ele pode ser uma composio dos documentos especificao de requisitos e plano de aquisio.

Pre-p8

4.3 Seleo do fornecedor 4.3.1 Objetivo O propsito da atividade de seleo do fornecedor escolher a organizao que ser responsvel pelo desenvolvimento e entrega do S&SC, em conformidade com os requisitos estabelecidos. A execuo desta atividade busca identificar o fornecedor adequado aos requisitos estabelecidos, levando-se em conta uma combinao harmoniosa entre resultados a serem obtidos, prazos, recursos e riscos envolvidos. Como consequncia ser

MPS.BR-Guia de Aquisio:2011

15/96

escolhido o fornecedor que prestar o servio at o final do contrato. As tarefas previstas compreendem: Avaliar a capacidade dos fornecedores (ver Sel-t1); Selecionar o fornecedor (ver Sel-t2); e Preparar e negociar um contrato (ver Sel-t3). 4.3.2 Tarefas previstas Id. Sel-t1 Tarefa Avaliar a capacidade dos fornecedores
Descrio:

Avaliar a capacidade dos fornecedores potenciais mediante os requisitos definidos e de acordo com os critrios de seleo de fornecedores. Esta tarefa importante principalmente quando se pretende fazer uma seleo prvia de fornecedores, levando-se em conta os critrios de seleo estabelecidos pelo adquirente. H situaes em que organizaes adquirentes utilizam um banco de possveis fornecedores, selecionados a partir de critrios gerais. Neste caso, a seleo para uma aquisio especfica feita a partir da aplicao dos critrios de seleo estabelecidos para esta aquisio nos fornecedores potenciais que fazem parte do banco existente na organizao.
Produtos requeridos:

Sel-p1 - Relatrio de auditoria ou de avaliao dos fornecedores Sel-p2 - Especificao de requisitos Sel-p3 - Pedido de proposta
NOTA: Com foco nos critrios de seleo de fornecedores. Produtos gerados:

Sel-p4 - Registro de fornecedores preferenciais Sel-p5 - Registro de contatos ocorridos Sel-t2 Selecionar o fornecedor
Descrio:

Selecionar o fornecedor a partir da avaliao das propostas recebidas. Nesta tarefa so confrontadas as caractersticas do fornecedor e as suas solues tcnicas apresentadas com os requisitos e critrios de seleo definidos. Dependendo do que foi definido nos critrios de seleo, esta tarefa poder requerer avaliao dos processos de software dos fornecedores ou avaliao da qualidade de produtos de software (principalmente quando da seleo de algum produto especfico).

MPS.BR-Guia de Aquisio:2011

16/96

Produtos Requeridos:

Sel-p4 - Registro de fornecedores preferenciais Sel-p3 - Pedido de proposta Sel-p6 - Proposta do fornecedor Sel-p2 - Especificao de requisitos
Produtos gerados:

Sel-p7 - Relatrio de avaliao das propostas dos fornecedores Sel-p8 - Resultado da anlise da avaliao dos fornecedores Sel-p5 - Registro de contatos ocorridos Sel-p9 - Registro de apoio a reunies
NOTA: Documento onde so registrados as reunies e os materiais apresentados pelos fornecedores durante a apresentao de sua proposta.

Sel-t3

Preparar e negociar um contrato Negociar um contrato3 com o fornecedor selecionado, expressando as expectativas do adquirente e as responsabilidades e direitos das partes envolvidas (adquirente e fornecedor). Definido o fornecedor e a proposta tcnica a ser implementada, esta tarefa dever contemplar uma reviso do plano de aquisio nos tpicos de monitorao da capacidade do fornecedor e dos riscos e mecanismos de mitigao, devendo ser considerada a necessidade de incluso ou complementao destes aspectos no contrato a ser firmado entre as partes.
Produtos Requeridos

Sel-p3 - Pedido de proposta Sel-p6 - Proposta do fornecedor Sel-p9 - Registro de apoio a reunies Sel-p2 - Especificao de requisitos
Nota: Normalmente includa no Pedido de proposta

Sel-p10 - Plano de aquisio


NOTA: Principalmente os aspectos de monitorao do fornecedor e de riscos. Produtos gerados:

Sel-p11 - Contrato Sel-p12 - Registro de reviso de contrato Sel-p9 - Registro de apoio a reunies

No caso de instituies pblicas, o contrato elaborado antes da atividade Seleo do fornecedor com base no plano de aquisio elaborado e na legislao relacionada. No havendo, portanto, possibilidade de reviso do plano de aquisio ou complementao do contrato.

MPS.BR-Guia de Aquisio:2011

17/96

NOTA: Documento onde so registradas as reunies realizadas durante a negociao do contrato com o fornecedor selecionado.

Sel-p5 - Registro de contatos ocorridos

4.3.3 Produtos requeridos e gerados Id. Sel-p1 Produtos /tarefas Descrio

Relatrio de auditoria ou de Documento contendo a avaliao dos avaliao dos fornecedores fornecedores segundo os critrios de seleo definidos. Especificao de requisitos Documento que especifica os requisitos e restries definidas pelo cliente, incluindo requisitos dos interessados (stakeholders), do sistema (quando for o caso), do software, de projeto, de manuteno, de treinamento e de implantao, restries legais, financeiras, de prazo e de nmero de usurios. Documento que caracteriza o S&SC e as condies de entrega, alm das condies gerais esperadas da aquisio, prazos e valores envolvidos, critrios de seleo e outras questes formais a serem seguidas.

Sel-p2

Sel-p3

Pedido de proposta (ver anexo B)

Sel-p4

Registro de preferenciais Registro ocorridos de

fornecedores Documento que registra os fornecedores potenciais (preferenciais) segundo o relatrio de avaliao de fornecedores. contactos Documento que registra todas as comunicaes formais ocorridas entre as partes (por exemplo, por telefone, carta, fax, e-mail, entre outras). Documento que descreve o entendimento do problema pelo fornecedor, sua abordagem e suas sugestes de soluo tcnica, alm do plano de entrega do S&SC e as condies financeiras da proposta.

Sel-p5

Sel-p6

Proposta do fornecedor (ver anexo C)

Sel-p7

Relatrio de avaliao das Documento que registra a avaliao da propostas dos fornecedores capacidade do fornecedor e das suas respectivas propostas, considerando a soluo tcnica proposta e o seu custo. Resultado da anlise da Documento que registra o resultado da avaliao dos fornecedores seleo do fornecedor tendo como base o

Sel-p8

MPS.BR-Guia de Aquisio:2011

18/96

relatrio de recebidas. Sel-p9 Registro de apoio a reunies

avaliao

das

propostas

Ata das reunies ocorridas abordando aspectos como objetivo da reunio, participantes, local e data, assuntos tratados, itens identificados, questes que permaneceram pendentes e agenda da prxima reunio. Documento que define os objetivos especficos a serem alcanados com a aquisio, os riscos envolvidos e um plano de projeto, contemplando itens como: prazos, custos, requisitos e restries, critrios de seleo de fornecedores, produtos e servios a serem fornecidos, critrios de aceitao do S&SC, responsabilidades das organizaes envolvidas na aquisio, riscos envolvidos e mecanismos de controle (como os produtos gerados e os processos utilizados pelo fornecedor sero monitorados). Documento onde so estabelecidos os aspectos financeiros, tcnicos e legais referentes contratao do S&SC, assim como as expectativas e responsabilidades das partes envolvidas.

Sel-p10 Plano de aquisio (ver anexo A)

Sel-p11 Contrato (ver anexo D)

Sel-p12 Registro contrato

de

reviso

de Documento onde so registradas as alteraes ou modificaes do contrato requeridas por qualquer uma das partes.

4.4 Monitorao do contrato 4.4.1 Objetivo O propsito da atividade de monitorao do contrato acompanhar e garantir o desempenho do fornecedor mediante os termos do contrato. A execuo desta atividade fundamental para monitorar o desenvolvimento do S&SC e da relao adquirente-fornecedor durante todo o perodo do contrato estabelecido. As avaliaes realizadas ao longo do desenvolvimento do contrato permitem identificar problemas, tomar decises gerenciais, projetar a qualidade final esperada para o S&SC e minimizar riscos. Dependendo da abordagem adotada, os resultados de avaliaes intermedirias podero ser utilizados nas tarefas da atividade de aceitao. As tarefas previstas compreendem: Estabelecer e manter comunicaes (ver Mon-t1); Trocar informao sobre o progresso tcnico (ver Mon-t2);

MPS.BR-Guia de Aquisio:2011

19/96

Revisar o desempenho do fornecedor (ver Mon-t3); Monitorar a aquisio (ver Mon-t4); Obter acordo quanto s alteraes (ver Mon-t5); e Acompanhar problemas (ver Mon-t6). 4.4.2 Tarefas previstas Id. Mon-t1 Tarefa Estabelecer e manter comunicaes
Descrio:

Estabelecer e manter um canal de comunicao entre o fornecedor e o adquirente. Esta tarefa fundamental, pois define a forma de comunicao entre as partes (por exemplo, cronograma, representantes, documentos utilizados, reunies, revises conjuntas) a ser adotada durante todo o perodo vigente do contrato. Esta comunicao estabelecida, bem como os produtos requeridos e gerados, devem ser considerados em todas as demais tarefas dessa atividade.
Produtos requeridos:

Mon-p1 - Contrato
NOTA: As clusulas contratuais formam a base para definio da forma de monitorao das tarefas executadas.

Mon-p2 - Proposta do fornecedor


NOTA: A proposta do fornecedor poder conter detalhes complementares ao contrato e que devem ser levados em conta na monitorao.

Mon-p3 - Registro de apoio a reunies.


NOTA: imprescindvel o registro de discusses e definies ocorridas em reunies conjuntas. Produtos gerados:

Mon-p3 - Registros de apoio a reunies Mon-p4 - Registro do status do progresso. Mon-p5 - Registro de contactos ocorridos. Mon-t2 Trocar informaes sobre o progresso tcnico
Descrio:

Utilizar o canal de comunicao para trocar informaes sobre o progresso tcnico do fornecedor, alm de aspectos de custos e a identificao de possveis riscos. Esta troca de informaes poder ocorrer durante as tarefas tpicas de desenvolvimento do projeto (por exemplo, no levantamento de requisitos, aprovao de artefatos, reunies de esclarecimentos, entre outros) podendo, no entanto, fornecer informaes importantes sobre a evoluo tcnica do projeto.

MPS.BR-Guia de Aquisio:2011

20/96

Produtos requeridos:

Mon-p1- Contrato Mon-p2 - Proposta do fornecedor Mon-p3 - Registro de apoio a reunies


Produtos gerados:

Mon-p3 - Registros de apoio a reunies Mon-p4 - Registro do status do progresso Mon-p5 - Registro de contactos ocorridos Mon-p6 - Registro de revises
NOTA: importante o registro das revises conjuntas ocorridas para possveis esclarecimentos futuros e para o histrico do projeto.

Mon-t3

Revisar o desempenho do fornecedor


Descrio:

Revisar, regularmente, aspectos do desenvolvimento com o fornecedor, tendo como base os termos do contrato. Os aspectos incluem questes tcnicas, de qualidade, custos e prazos. A reviso um evento formal que ocorre em marcos do projeto. Dever ser planejada antecipadamente e ocorrer em pontos bem definidos que possam trazer o melhor retorno com relao ao andamento do projeto. Como pode envolver um expressivo volume de recursos, a quantidade de revises dever ser proporcional criticidade do projeto. Em geral, dever valer-se de medidas coletadas ao longo das prprias tarefas do projeto, porm poder demandar medies especficas sobre os artefatos produzidos no projeto. Esta tarefa poder ser executada pelo prprio adquirente ou, dependendo de sua complexidade, poder requerer a utilizao de recursos de terceira-parte.
Produtos requeridos:

Mon-p1- Contrato
NOTA: Se o contrato no contemplar as regras que tenham sido definidas para monitorao, outros documentos complementares podem ser requeridos.

Mon-p2 - Proposta do fornecedor Mon-p3 - Registros de apoio a reunies Mon-p7 - Concordncia com os requisitos do contrato
NOTA: O contrato dever refletir eventuais alteraes que possam ocorrer conforme referido na tarefa Mon-t5.

Mon-p13- S&SC
Produtos gerados:

Mon-p3 - Registros de apoio a reunies Mon-p4 - Registro do status do progresso

MPS.BR-Guia de Aquisio:2011

21/96

Mon-p5 - Registro de contactos ocorridos Mon-p8 - Resultado da anlise do desempenho do fornecedor Mon-p9 - Registro de aceitao do desempenho do fornecedor
NOTA: A aceitao dos produtos entregues na reviso deve estar vinculada ao contedo do resultado da anlise do desempenho do fornecedor.

Mon-t4

Monitorar a aquisio
Descrio:

Monitorar a aquisio, tendo como base o contrato, para que o progresso possa ser avaliado, garantindo que aspectos como custo, qualidade e prazo sejam atendidos. A monitorao do projeto uma tarefa executada por meio da anlise de medidas obtidas no processo executado. Os resultados da reviso do desempenho do fornecedor (Mon-t3) tambm devem ser considerados durante a monitorao. A anlise destas medidas permite a obteno de indicadores de desempenho do projeto na situao em que foram obtidas as medidas, alm da projeo da situao futura do projeto. A monitorao deve envolver aspectos que caracterizam o progresso do projeto, tais como atendimento aos requisitos, custos e prazos, os riscos envolvidos, nvel de problemas que esto sendo enfrentados e aderncia ao processo que foi contratado. A monitorao a base para a tomada de aes gerenciais, tais como reviso de prazos e requisitos, alocao de recursos, interrupo de atividades, aceitao (ou no) de artefatos, aplicao de penalidades, solicitao do envolvimento de interessados (stakeholders) ou at mesmo a interrupo do contrato.
Produtos requeridos:

Mon-p1 Contrato
NOTA: Se o contrato no contemplar as regras que tenham sido definidas para monitorao, outros documentos complementares podem ser requeridos.

Mon-p2 - Proposta do fornecedor Mon-p3 - Registros de apoio a reunies Mon-p7 - Concordncia com os requisitos do contrato
NOTA: O contrato dever refletir eventuais alteraes que possam ocorrer conforme referido na tarefa Mon-t5.

Mon-p8 - Resultado da anlise do desempenho do fornecedor


NOTA: Os resultados obtidos em Mon-t3 servem como insumo na tarefa de monitorao.

Mon-p13- S&SC
Produtos gerados:

Mon-p3 - Registros de apoio a reunies Mon-p4 - Registro do status do progresso

MPS.BR-Guia de Aquisio:2011

22/96

Mon-p5 - Registro de contactos ocorridos Mon-p8 - Resultado da anlise do desempenho do fornecedor


NOTA: Esta tarefa tambm produz resultados da anlise do desempenho do fornecedor

Mon-p9 - Registro de aceitao do desempenho do fornecedor


NOTA: A aceitao dos produtos entregues na monitorao deve estar vinculada ao contedo do resultado da anlise do desempenho do fornecedor.

Mon-t5

Obter acordo quanto s alteraes


Descrio:

As alteraes propostas por qualquer uma das partes devem ser negociadas e seus resultados devem ser documentados no contrato. O contrato deve estar preparado para a necessidade de implementar alteraes em relao aos requisitos ou outras condies inicialmente estabelecidas. Estas alteraes podem vir a significar novas responsabilidades para as partes alm de poder influenciar os prazos, custos, qualidade e benefcios envolvidos. Convm que o mecanismo utilizado para controle de mudanas considere os papis e responsabilidades envolvidas, o nvel de formalidade necessrio e a forma de comunicao para os interessados (stakeholders) afetados.
Produtos requeridos:

Mon-p1 - Contrato Mon-p2 - Proposta do fornecedor Mon-p3 - Registro de apoio a reunies Mon-p7 - Concordncia com os requisitos do contrato
NOTA: A situao dos requisitos estabelecidos ou atualizados em alteraes anteriores ser a base para qualquer nova solicitao.

Mon-p10 - Pedidos de alteraes pelo adquirente


NOTA: Este registro importantssimo para substanciar o acordo assinado no contrato e analisar possveis adendos a ele. Produtos gerados:

Mon-p3 - Registros de apoio a reunies Mon-p5 - Registro de contactos ocorridos Mon-p7 - Concordncia com os requisitos do contrato
NOTA: Eventuais alteraes introduzidas devero ser aprovadas pelos interessados (stakeholders) e refletidas no contrato entre as partes.

Mon-t6

Acompanhar problemas
Descrio:

Problemas que surgirem durante a execuo do contrato devero ser registrados e acompanhados at a sua soluo pelas partes.

MPS.BR-Guia de Aquisio:2011

23/96

A adoo de uma soluo de acompanhamento de problemas permite que os problemas identificados sejam declarados e designados para os respectivos responsveis at a sua soluo definitiva ou criao de solues de contorno aceitveis. Aes de gesto sobre os dados obtidos podero evitar a recorrncia de problemas, melhorando a qualidade do processo adotado.
Produtos requeridos:

Mon-p11 - Sistema de acompanhamento de problemas


NOTA: Este sistema pode ser manual ou automatizado e facilitar o gerenciamento do projeto. Produtos gerados:

Mon-p12 - Registros no sistema de acompanhamento de problemas


.

4.4.3 Produtos Requeridos e gerados Id. Mon-p1 Produtos Contrato (ver anexo D) Descrio Documento onde so estabelecidos os aspectos financeiros, tcnicos e legais referentes contratao do S&SC, assim como as expectativas e responsabilidades das partes envolvidas. Documento que descreve o entendimento do problema pelo fornecedor, sua abordagem e suas sugestes de soluo tcnica. a Ata das reunies ocorridas abordando aspectos como objetivo da reunio, participantes, local e data, assuntos tratados, itens identificados, questes que permaneceram pendentes e agenda da prxima reunio. do Documento que registra, em uma determinada data, a situao do projeto de aquisio no que diz respeito a custo, prazo e requisitos atendidos.

Mon-p2

Proposta do fornecedor (ver anexo C)

Mon-p3

Registros reunies

de

apoio

Mon-p4

Registro do progresso

status

Mon-p5

Registro ocorridos

de

contactos Documento que registra todas as comunicaes formais ocorridas entre as partes (por exemplo, por telefone, carta, fax, e-mail, entre outras). Documento que registra data, produto ou processo revisado, mtodo de reviso

Mon-p6

Registro de revises (ver anexo E)

MPS.BR-Guia de Aquisio:2011

24/96

utilizado, o responsvel pela reviso e o resultado (bom, precisa melhorar, ruim). O registro de revises tambm contm informaes gerenciais do projeto e os riscos identificados durante a reviso. Mon-p7 Concordncia com requisitos do contrato os Documento que registra a concordncia dos interessados (stakeholders) relevantes com os requisitos do contrato e os compromissos estabelecidos para as partes.

Mon-p8

Resultado da anlise do Documento que registra o desempenho desempenho do fornecedor do fornecedor, se ele est ou no respondendo s expectativas esperadas e cumprindo o acordo realizado ou se o caso de aplicar penalidades, cancelar o contrato ou outra soluo. Registro de aceitao do Documento que registra a aceitao do desempenho do fornecedor S&SC entregues e do desempenho do fornecedor, dando continuidade ao contrato. Pedidos de alteraes pelo Documento onde so registrados os adquirente pedidos do adquirente, como alterao de requisitos ou incluso de novos. Sistema acompanhamento problemas Registros no sistema de acompanhamento de problemas S&SC de Sistemtica que permita registrar e de acompanhar as tarefas necessrias para soluo dos problemas identificados. Registros que permitam acompanhar o status dos problemas pendentes e solucionados. Artefatos do S&SC que estaro sujeitos s tarefas relacionadas atividade de monitorao do contrato.

Mon-p9

Mon-p10

Mon-p11

Mon-p12

Mon-p13

4.5 Aceitao pelo cliente 4.5.1 Objetivo O propsito da atividade de aceitao pelo cliente aprovar S&SC entregues pelo fornecedor quando todos os critrios de aceitao estiverem satisfeitos. Nesta atividade so refinados os critrios de aceitao que foram definidos no plano de projeto e incorporados no pedido de proposta e no contrato. As avaliaes podem ser conduzidas no decorrer do contrato, por uma abordagem envolvendo mltiplas iteraes e entregas de produtos, ou por meio de uma entrega nica. Os S&SC entregues so analisados para identificar a conformidade aos critrios

MPS.BR-Guia de Aquisio:2011

25/96

estabelecidos. As tarefas de avaliao so concebidas de modo a reduzir a interferncia com as avaliaes executadas pelo fornecedor e a duplicao de esforos de avaliao. No havendo aprovao do S&SC, e dependendo das clusulas contratuais, podem ser planejados e implementados ajustes para que o produto seja submetido a uma nova avaliao. Este ciclo ocorre enquanto o produto no aprovado, ou at que seja definitivamente rejeitado. As tarefas previstas compreendem: Definir critrios de aceitao (ver Ace-t1); Avaliar o produto entregue (ver Ace-t2); Manter conformidade com o contrato (ver Ace-t3); e Aceitar o S&SC (ver Ace-t4). 4.5.2 Tarefas previstas Id. Ace-t1 Tarefa Preparar a aceitao
Descrio:

Preparar a aceitao do S&SC levando em conta os critrios de aceitao do S&SC, bem como a forma de avaliao a ser aplicada. Nesta tarefa devero ser feitas as adaptaes finais nos critrios de aceitao e no plano de testes que foram elaborados na atividade de preparao da aquisio, incluindo os casos de testes, dados de testes, procedimentos de teste e ambiente de teste. Neste momento devem ser levados em conta no apenas os requisitos estabelecidos mas as suas formas de implementao atravs das diversas funes do software. Esta tarefa requer o estabelecimento de uma correlao entre os requisitos especificados e as funes do software que foram implementadas. Os requisitos abrangidos pelos critrios de aceitao devero ser desdobrados em casos de teste das funes do software que permitam constatar o atendimento s medidas estabelecidas.
Produtos requeridos:

Ace-p1 - Contrato Ace-p2 - Plano de teste do S&SC para sua aceitao


NOTA: verso elaborada na atividade de preparao da aquisio.

Ace-p3 - Plano de aquisio Ace-p4 - Proposta do fornecedor


NOTA: A proposta do fornecedor pode incluir itens que suplementam os requisitos inicialmente estabelecidos.

Ace-p5 - S&SC
Produtos gerados:

Ace-p2 - Plano de teste do S&SC para sua aceitao

MPS.BR-Guia de Aquisio:2011

26/96

NOTA: Plano de teste atualizado, considerando a forma de implementao dos requisitos especificados.

Ace-t2

Avaliar o S&SC entregue


Descrio:

Avaliar o S&SC com base nos critrios de aceitao definidos. Nesta tarefa so complementados os testes necessrios para confirmar o atendimento aos critrios de aceitao definidos. Dependendo da abordagem utilizada para desenvolvimento do S&SC, parte das tarefas de avaliao poder ser executada ao longo da execuo do projeto.
Produtos requeridos:

Ace-p2 - Plano de teste do S&SC para sua aceitao Ace-p3 - Plano de aquisio
NOTA: O Plano de aquisio pode ser til nesta tarefa, pois inclui a definio dos critrios de aceitao estabelecidos na atividade de preparao da aquisio.

Ace-p4 - Proposta do fornecedor Ace-p5 - S&SC Ace-p6 - Especificao de requisitos


Produtos gerados:

Ace-p7 - Relatrio de resultados de testes Ace-t3 Manter conformidade com o contrato


Descrio:

Resolver qualquer aspecto relacionado aceitao, de acordo com os procedimentos estabelecidos no contrato. Esta tarefa apenas assegura que o contrato dever ser utilizado como referncia para dirimir questes que possam surgir no processo de aceitao e para garantir que o S&SC entregues esto de acordo com o contrato.
Produtos requeridos:

Ace-p1 - Contrato
Produtos gerados:

Ace-p8 - Registro de apoio a reunies Ace-t4 Aceitar o S&SC


Descrio:

Aceitar o S&SC e comunicar sua aceitao ao fornecedor. Esta tarefa representa o rito de passagem do S&SC de seu estgio de fornecimento para o de recebimento pelo cliente. Dever estar completamente respaldada pelos relatrios produzidos no

MPS.BR-Guia de Aquisio:2011

27/96

processo de avaliao e pela observao de todos os critrios de aceitao definidos anteriormente. Alm dos critrios de avaliao do produto de software entregue, devem tambm ser considerados os critrios relacionados aos servios associados, por exemplo, ao processo de implantao do software e ao atendimento das condies para que este entre em processo de manuteno.
Produtos requeridos:

Ace-p1 - Contrato Ace-p3 - Plano de aquisio Ace-p4 - Proposta do fornecedor Ace-p5 - S&SC Ace-p6 - Especificao de requisitos Ace-p7 - Relatrio de resultados de testes
Produtos gerados:

Ace-p8 - Relatrio de aceitao do S&SC 4.5.3 Produtos requeridos e gerados Id. Ace-p1 Produtos Contrato (ver anexo D) Descrio Documento onde so estabelecidos os aspectos financeiros, tcnicos e legais referentes contratao do S&SC, assim como as expectativas e responsabilidades das partes envolvidas.

Ace-p2

Plano de teste do S&SC para Documento que define as condies, sua aceitao tarefas e responsabilidades pela execuo dos testes necessrios para a aceitao do S&SC a ser adquirido. Para a elaborao deste documento deve-se levar em conta os requisitos desejados para o S&SC, bem como os critrios estabelecidos para a aceitao. Este documento de orientao ser atualizado e detalhado medida que sejam especificadas as funes do software ao longo da execuo do contrato. Plano de aquisio (ver anexo A) Documento que define os objetivos especficos a serem alcanados com a aquisio, os riscos envolvidos e um plano de projeto, contemplando itens como: prazos, custos, requisitos e restries, critrios de seleo de fornecedores, produtos e servios a serem fornecidos,

Ace-p3

MPS.BR-Guia de Aquisio:2011

28/96

critrios de aceitao do S&SC, responsabilidades das organizaes envolvidas na aquisio, riscos envolvidos e mecanismos de controle (como os produtos gerados e os processos utilizados pelo fornecedor sero monitorados). Ace-p4 Proposta do fornecedor (ver Anexo C) Documento que descreve o entendimento do problema pelo fornecedor, sua abordagem e suas sugestes de soluo tcnica. Conjunto de programas de computador, procedimentos e possvel documentao e dados associados que devem ser entregues ao cliente, bem como servios correlatos ao software entregue, tais como manuteno, treinamento, integrao com outros sistemas, implantao, entre outros. Documento que especifica os requisitos e restries definidas pelo cliente, incluindo requisitos dos interessados (stakeholders), do sistema (quando for o caso), do software, de projeto, de manuteno, de treinamento e de implantao, restries legais, financeiras, de prazo e de nmero de usurios. Documento que apresenta os resultados dos testes do software, sejam eles parciais, testes de integrao das partes do produto, teste final do produto e teste em operao no ambiente do cliente. Documento que apresenta a memria dos resultados dos procedimentos utilizados que levaram a aceitao ou rejeio do S&SC. Ata das reunies ocorridas abordando aspectos como objetivo da reunio, participantes, local e data, assuntos tratados, itens identificados, questes que permaneceram pendentes e agenda da prxima reunio.

Ace-p5

S&SC

Ace-p6

Especificao de requisitos

Ace-p7

Relatrio de resultados de testes

Ace-p8

Relatrio de aceitao do S&SC

Ace-p8

Registro de apoio a reunies

MPS.BR-Guia de Aquisio:2011

29/96

MPS.BR-Guia de Aquisio:2011

30/96

Anexo A Plano de aquisio

PLANO DE AQUISIO < S&SC >

Este documento visa orientar a aquisio de S&SC para < objetivo esperado do S&SC> da < nome da empresa >. 1. Objetivo da aquisio: (Descrio dos objetivos a serem atendidos com a aquisio do S&SC). Exemplo: Pretende-se, com a aquisio do S&SC, controlar as finanas da instituio, de forma a agilizar os processos administrativos, aliviando a alta carga de trabalho da tesouraria, melhorando e dinamizando as rotinas administrativas e os controles financeiros; e melhorar a qualidade das informaes gerenciais; 2. Requisitos 2.1 Requisitos dos interessados (stakeholders) (Lista de necessidades dos interessados (stakeholders) na utilizao do software a ser adquirido. Considerar os diversos stakeholders e contextos do uso software. A definio de prioridades pode ser importante para estabelecer critrios de aceitao e plano de verses do software. Eventualmente esta relao de requisitos pode se constituir num documento anexo ao plano de aquisio). Exemplos: Agilizar os processos administrativos. Amenizar a alta carga de trabalho da tesouraria. Permitir o controle das contas a receber. 2.2 Requisitos do sistema (Descrio do contexto geral no qual o software a ser adquirido estar inserido, podendo contemplar ambiente tecnolgico, de processos e at mesmo de pessoas envolvidas). Exemplo: O software deve trabalhar em rede de microcomputadores e ambiente Windows, de maneira a aproveitar a infra-estrutura existente, utilizando o banco de dados FireBird, que o banco corporativo da organizao. O software ser um dos componentes do processo de aquisio de insumos da empresa, contemplando as atividades a, b e c. 2.3 Requisitos do software ( a derivao dos requisitos dos interessados (stakeholders) que foram mapeados atravs dos sistemas. Os requisitos do software dividem-se em Requisitos Funcionais que descrevem as funes a serem realizadas pelo software

MPS.BR-Guia de Aquisio:2011

31/96

a ser adquirido e Requisitos de Qualidade que descrevem as caractersticas de qualidade consideradas importantes no software). Exemplos de requisitos funcionais: O software dever permitir cadastrar usurio com seu grau de sigilo. O software dever permitir redigir documento. O software dever permitir visualizar documento. Exemplos de requisitos de qualidade: Usabilidade: estilo ou princpios de dilogo que so aplicveis; tipo de documentao a ser entregue (on-line, manuais de usurio); Portabilidade: Regras de portabilidade que devero ser adotadas (tanto para a parte de servidores quanto para acesso via estaes de trabalho); Interoperabilidade: integrao das aplicaes novas com os bancos de dados e aplicaes legadas; Manutenibilidade: tipos e caractersticas dos artefatos gerados, de modo a permitir a manuteno por parte do contratado, bem como para facilitar eventuais repasses de conhecimento. 2.4 Requisitos de projeto (Estabelecer o ciclo de vida de desenvolvimento a ser adotado, tcnicas, ferramentas, tecnologias, mtodos, forma de gesto e de documentao). Exemplo: O software a ser adquirido dever ser desenvolvido segundo a abordagem do Processo Unificado, gerando artefatos segundo a notao UML e com tecnologia J2EE. 2.5 Requisitos de manuteno (Estabelecimento da forma como ser conduzida a manuteno do software a ser adquirido. Definir o custo e o canal de comunicao entre o fornecedor e o cliente para o atendimento de possveis problemas). Exemplo: A correo de problemas considerados crticos dever ser providenciada em at 24 horas aps a sua identificao pelo usurio, ou, no sendo vivel, dever ser estabelecida uma soluo de contorno; A cada 2 anos dever ser promovida uma atualizao tecnolgica do software considerando as evolues que ocorrerem no seu ambiente de operao. 2.6 Requisitos de treinamento (Estabelecimento de um plano de treinamento para a operao do software a ser adquirido. Definir as pessoas que participaro do treinamento, o nmero de apresentaes/aulas que sero necessrias assim como o material e o ambiente a ser utilizado). Exemplo: A organizao fornecedora dever oferecer 3 apresentaes/aulas aos usurios do software. Dever fazer parte do material de treinamento o

MPS.BR-Guia de Aquisio:2011

32/96

manual do usurio. O treinamento ser realizado nas dependncias da organizao cliente. 2.7 Requisitos de implantao (Estabelecimento da forma como ser conduzida a implantao do software a ser adquirido. Definir o ambiente e os equipamentos necessrios). Exemplo: A implantao do software ser realizada em 3 dias. A organizao fornecedora dever acompanhar as instalaes dos novos equipamentos e do novo software. Ao se implantar o software, o banco de dados dever estar preenchido com os dados reais. 3. Termos contratuais (Descrio de aspectos relacionados ao contrato). 3.1 Tipo de contrato a ser empregado (Tipo de contrato a ser utilizado) Exemplo: Contrato de preo fixo, contrato de custos reembolsveis ou contrato de preo unitrio por ponto por funo. 3.2 Multas e penalidades (Valor e as condies de ocorrncia de multas de ambas as partes). Exemplo: A contratada, ressalvados os casos fortuitos ou de fora maior, devidamente comprovados, e garantida a sua prvia defesa no respectivo processo de apurao dos fatos, estar sujeita s seguintes penalidades: a. advertncia, por escrito, na primeira falta cometida; b. multas, no valor de at 20% do valor total estabelecido; c. suspenso temporria de participao em licitao e impedimento de contratar com o cliente, por prazo de at dois (02) anos. 3.3 Direitos de distribuio, uso e propriedade do software (Estabelecimento dos direitos de distribuio, uso e propriedade do software, como, por exemplo, o nmero de cpias a serem distribudas e a propriedade do cdigo fonte, entre outros). Exemplo: O software desenvolvido estar sob uma licena de uso restrito ao contratante, protegidos por direitos autorais e de propriedade. A cpia, redistribuio, engenharia reversa e modificao do software proprietrio so proibidas. Os programas de software sero de uso proprietrio da organizao cliente, inclusive seus cdigos-fonte e documentao. A organizao fornecedora no tem direito, disponibilidade ou qualquer outro tipo de participao em nenhum destes programas ou em qualquer cpia, modificao ou parte agregada de qualquer um destes programas.

MPS.BR-Guia de Aquisio:2011

33/96

3.4 Garantia do S&SC (Garantia do S&SC descrevendo o prazo de validade, a abrangncia (por exemplo, erros no software, problemas na instalao, documentao, integrao com outros sistemas) e os procedimentos para o seu uso). Exemplo: Durante o prazo de garantia, de seis meses, a contratada dever prestar servios de manuteno, esclarecendo dvidas e corrigindo eventuais falhas que impossibilitem o uso normal do software. 4. Termos financeiros (Descrio de questes financeiras relacionadas aquisio). 4.1 Oramento do projeto (Valor monetrio disponvel para o projeto de aquisio). Exemplo: O valor disponvel para a aquisio do software de R$ 1.000.000,00 (Um milho de reais). 4.2 Fonte de recursos para a aquisio (Descrio da origem da verba alocada para a aquisio). Exemplo: A verba para o projeto de aquisio fruto de uma parceria com organizaes afins. 4.3 Formas de pagamento da aquisio (Descrio dos perodos de pagamento ao fornecedor, o nmero de parcelas o valor de cada parcela). Exemplo: O pagamento referente aquisio ser realizado em quatro parcelas no valor de R$250.000,00 (duzentos e cinquenta mil reais) cada, ao longo de um perodo de um ano. 5. Termos tcnicos (Descrio de aspectos tcnicos considerados importantes para a aquisio). 5.1 Procedimentos de confidencialidade (Estabelecimento do tratamento que deve ser dado s informaes sigilosas confiadas ao fornecedor, bem como as condies de acesso s instalaes do adquirente, identificao dos participantes do projeto, entre outros). Exemplo: de responsabilidade do fornecedor proteger e devolver toda e qualquer documentao sigilosa emprestada pela organizao cliente durante a elaborao do S&SC. O fornecedor dever eleger um responsvel pelo

MPS.BR-Guia de Aquisio:2011

34/96

pedido, guarda e devoluo dos documentos necessrios durante a aquisio. 5.2 Especificao do canal de comunicao (Estabelecimento de um mecanismo de comunicao entre os participantes do projeto de aquisio e o fornecedor: via e-mail, pessoalmente ou por telefone,sempre que houver necessidade). Exemplo: Sempre que houver necessidade, a troca de informaes entre a organizao cliente e o fornecedor poder ser realizada via e-mail e/ou pessoalmente. Tanto os e-mails trocados quanto as reunies presenciais devem ser registrados e armazenados. 5.3 Procedimentos para mudanas (Estabelecimento de como, quando e por quem sero executadas as alteraes nos requisitos e no contrato). Exemplo: Tanto a organizao cliente quanto a organizao fornecedora devero eleger um responsvel pela gerncia de pedidos de alterao de requisitos e de contrato. Sempre que houver a necessidade de alguma mudana, os representantes responsveis devero se reunir e chegar a um acordo sobre a realizao ou no da alterao em questo. 5.4 Procedimentos para tratamento de problemas (Procedimentos a serem adotados para registro, acompanhamento e soluo de problemas). Exemplo: medida que sejam identificados problemas que possam afetar os resultados do projeto para o adquirente, esses devero ser registrados, ter seus impactos analisados e encaminhamentos da soluo definidos, incluindo os responsveis pelas aes a serem tomadas, os prazos envolvidos e data da efetiva soluo. Problemas no mbito tcnico especfico dos projetos e que no afetem os resultados para o adquirente devero ser tratados pelos procedimentos internos de tratamento de problemas do fornecedor. 6. Lista de S&SC a serem entregues (Lista dos S&SC que devem ser entregues pelo fornecedor no final do contrato. Entre eles, devem ser considerados os servios de suporte esperados do fornecedor). Exemplo: Os produtos a serem entregues ao final do contrato so: (i) o software instalado em seu ambiente de operao; (ii) os manuais do usurio, de instalao e do sistema; e (iii) os cdigos-fonte

MPS.BR-Guia de Aquisio:2011

35/96

7. Pontos de controle (Descrio dos marcos de controle do projeto, definidos por meio dos produtos de trabalho e dos processos do fornecedor que sero avaliados pelo adquirente durante o processo de aquisio, e o mtodo de avaliao, por exemplo: validao, auditoria e reviso conjunta, entre outros). Nome do Produto/Processo Mdulo 1 manuteno dados do BD Manual do usurio 8. Prazos estabelecidos (Especificao do cronograma para o ciclo de vida escolhido e seus marcos). Exemplo: O software a ser adquirido composto por quatro mdulos. O primeiro mdulo (xxxx) dever ser entregue, para testes do cliente, ao final de dois meses, a contar da data da assinatura do contrato. O segundo mdulo (yyyy) dever ser entregue trs meses aps a entrega do primeiro. O terceiro mdulo (zzzz) dever ser entregue trs meses aps a entrega do segundo mdulo e o quarto e ltimo mdulo (wwww) dever ser entregue quatro meses aps a entrega do terceiro mdulo. 9. Critrios de seleo do fornecedor (Descrio dos critrios a serem avaliados para julgamento da capacidade do fornecedor em atender ao contrato pretendido). Exemplo: Os critrios para a seleo do fornecedor so: (i) Situar-se na cidade do Rio de Janeiro; (ii) Ter mais de cinco anos de mercado; (iii) Ter experincia no domnio do problema; e (iv) Ter avaliao oficial MA-MPS nvel F 10. Critrios de aceitao do S&SC (Descrio de aspectos que devem ser satisfeitos para que o S&SC sejam aceitos. Teoricamente todos os requisitos teriam que ser avaliados, o que nem sempre prtico. Estes so critrios que sero avaliados para apoiar o processo de aceitao. A garantia pode assegurar que os demais requisitos tero que ser atendidos durante o seu prazo de vigncia). 10.1 Requisitos funcionais do software (Descrio das funes do software que sero avaliadas para a definio de sua aceitao). Mtodo da Avaliao

Testes dos Reviso Conjunta

MPS.BR-Guia de Aquisio:2011

36/96

Exemplo: O software s ser aceito aps a validao com sucesso das funes de cadastramento, clculo e consultas gerenciais. 10.2 Requisitos de qualidade do software (Descrio das caractersticas de qualidade que sero avaliadas para a definio da aceitao do software). Exemplo: O software s ser aceito aps avaliao com sucesso dos requisitos referentes s seguintes caractersticas de qualidade: (i) segurana de acesso; (ii) usabilidade; (iii) comportamento em relao ao tempo; e (iv) portabilidade 10.3 Documentao disponvel (Especificao dos documentos que sero avaliados como condio de aceitao do S&SC, como: manual do usurio e de instalao, entre outros). Exemplo: O software a ser adquirido dever ser entregue juntamente com o manual do usurio, manual do sistema e manual de instalao. 11. Normas e modelos (Descrio de normas, modelos, leis, padres, prticas e convenes que devem ser seguidos pelo fornecedor). Exemplo: A organizao fornecedora dever seguir o modelo MPS.BR para o desenvolvimento de software e as normas adotadas pela organizao cliente com relao a padronizao da nomenclatura de variveis dos programas de software. 12. Responsabilidades do projeto (Definio das tarefas a serem desempenhadas no projeto, considerando o adquirente, o fornecedor e, quando houver, terceira-parte). Exemplo: A equipe do projeto de aquisio da organizao cliente dever fornecer, sempre que necessrio, informaes e documentos que sero utilizados pela organizao fornecedora. Fica tambm sob a responsabilidade da equipe do projeto de aquisio da organizao cliente a atividade de prover as informaes necessrias para o preenchimento do banco de dados. Alm das atividades tpicas do fornecedor, previstas no plano de projeto, dever executar funes de gerente de projeto, que atuar de forma global no projeto, assegurando que as aes sejam tomadas de forma adequada e a tempo para atender s necessidades de projeto;

MPS.BR-Guia de Aquisio:2011

37/96

13. Riscos e eventos (Descrio de riscos ou eventos que podem ocorrer durante a aquisio e como devem ser tratados). 13.1 Identificao do risco (Descrio do tipo de risco, por exemplo: atraso no cronograma, falta de recursos financeiros e humanos e falha de interpretao dos requisitos do software, entre outros). Exemplo: Um risco que pode ocorrer durante a execuo do projeto a complexidade de requisitos. 13.2 Probabilidade de ocorrncia (Descrio da probabilidade do risco ocorrer, por exemplo: alta, mdia ou baixa). Exemplo: A probabilidade de ocorrncia do risco identificado no item 13.1 alta. 13.3 Impacto no projeto (Descrio dos aspectos relevantes que podem afetar o projeto caso o risco ocorra, por exemplo: parar o projeto e falta de verbas para outras atividades, entre outros). Exemplo: Os impactos no projeto decorrentes do risco identificado no item 13.1 so: o alto ndice de alterao dos requisitos e cronograma ultrapassado. 13.4 Mitigao dos riscos (Descrio dos procedimentos para amenizar ou eliminar a ocorrncia do risco). Exemplo: Para mitigar o risco identificado no item 13.1 ser consultado um especialista no domnio do problema para esclarecer dvidas e orientar a atividade elicitao de requisitos do software. 13.5 - Plano de contingncia (Descrio dos procedimentos a serem tomados no caso do risco se concretizar). Exemplo: Caso o risco identificado no item 13.1 se concretize, poder ser necessrio considerar uma nova abordagem para complementao dos requisitos e para desenvolvimento do software, podendo adotar, por exemplo, a aplicao de prottipos.

MPS.BR-Guia de Aquisio:2011

38/96

Anexo B- Pedido de proposta

Pedido de proposta < Software >


Este documento visa apresentar subsdios para a elaborao de proposta de fornecimento de software para < aplicao do software > da < nome da empresa >. 1. Descrio da organizao cliente (Descrio do tipo, da estrutura, dos objetivos e metas da organizao cliente). Exemplo: O Colgio ABC, uma instituio de ensino que cobre desde do jardim de infncia at a concluso do segundo grau, hoje conta com um sistema informatizado de controle escolar para as atividades da secretaria. Porm, no setor de tesouraria os controles ainda so efetuados de forma manual, o que considerado crtico pelos mantenedores. Esse controle manual das atividades da tesouraria acarreta, entre outros problemas, sobrecarga de trabalho para alguns funcionrios, acmulo de papis, dificuldade para controlar os gastos e receitas por setor da escola, dificuldade no tratamento de informaes gerenciais e uma perda de qualidade no atendimento aos alunos e seus pais, devido morosidade das informaes. A mantenedora demonstrou a inteno de, aps melhorar o desempenho da tesouraria, substituir o software de controle da secretaria e integr-lo ao software de controle financeiro. Tambm h planos de, com a reforma do prdio administrativo, disponibilizar para os alunos e pais um terminal de consulta da sua situao escolar, inclusive financeira. (o contedo dos itens 2 a 14 semelhante aos itens correspondentes do plano de aquisio. Por vezes necessria alguma adaptao com relao a informaes estabelecidas no plano de aquisio que so de carter reservado organizao adquirente. Alguns aspectos especficos so comentados a seguir). 2. Objetivo da aquisio 3. Requisitos 3.1 Requisitos dos interessados (stakeholders) 3.2 Requisitos do sistema 3.3 Requisitos do software 3.4 Requisitos de projeto 3.5 Requisitos de manuteno 3.6 Requisitos de treinamento 3.7 Requisitos de implantao 4. Termos contratuais 4.1 Tipo de contrato a ser empregado 4.2 Multas e penalidades 4.3 Direitos de distribuio, uso e propriedade do software

MPS.BR-Guia de Aquisio:2011

39/96

4.4 Garantia do S&SC 5. Termos financeiros (Dependendo da organizao, s ser necessrio estabelecer o item 5.3, explicitando as formas de pagamento). 5.1 Oramento do projeto 5.2 Fonte de recursos para a aquisio 5.3 Formas de pagamento da aquisio 6. Termos tcnicos 6.1 Procedimentos de confidencialidade 6.2 Especificao do canal de comunicao 6.3 Procedimentos para mudanas 6.4 Procedimentos para tratamento de problemas 7. Lista de S&SC a serem entregues 8. Pontos de controle 9. Prazos estabelecidos 10. Critrios de seleo do fornecedor (No pedido de proposta pode ser conveniente orientar ao proponente quanto forma de apresentao da comprovao do cumprimento dos itens que sero adotados para seleo do fornecedor como, por exemplo, os tipos de atestados a serem obtidos para comprovao de experincia do fornecedor, atestados de qualificao tcnica dos tcnicos, forma de explicitao quanto ao atendimento de itens obrigatrios, entre outros). 11. Critrios de aceitao do S&SC 11.1 Requisitos funcionais do software 11.2 Requisitos de qualidade do software 11.3 Documentao disponvel 12. Normas e modelos 13. Responsabilidades do projeto 14. Riscos e eventos (O adquirente dever avaliar a convenincia de incluir este tpico. Dever explicit-lo no pedido de proposta apenas se os riscos puderem influenciar as condies a serem propostas pelo fornecedor). 14.1 Identificao do risco 14.2 Probabilidade de ocorrncia 14.3 - Impacto no projeto 14.4 Mitigao dos riscos 14.5 - Plano de contingncia

MPS.BR-Guia de Aquisio:2011

40/96

Anexo C - Proposta dos fornecedores 1. Propostas (Identificao, descrio da empresa, das capacidades, estimativas e outras caractersticas de cada fornecedor). 1.1 Identificao do fornecedor 1.2 Descrio da empresa e seu histrico (Descrio das principais caractersticas da empresa e seu tempo de mercado). 1.3 Clientes atuais e passados (Nome e contato dos clientes atuais e passados e os respectivos trabalhos realizados). 1.4 Posio financeira (Descrio dos bens patrimoniais e monetrios da empresa). 1.5 Descrio do entendimento do problema (Descrio de como o fornecedor entendeu o problema). 1.6 Abordagem tcnica (Descrio das tcnicas a serem utilizadas pelo fornecedor para resolver o problema). 1.7 Sugestes de solues (Descrio das solues, propostas pelo fornecedor, para resolver o problema). 1.8 Prticas de qualidade Descrio das prticas de qualidade empregadas pelo fornecedor, por exemplo: seguir processos definidos, verificao e validao de produtos. 1.9 Recursos de equipamento, ferramentas e outros (Descrio do hardware e software usados, pelo fornecedor, para resolver o problema). 1.10 Experincia na tcnica e no domnio (Descrio das experincias anteriores no domnio do problema e nas tcnicas usadas para resolv-lo). 1.11 Experincia da equipe (Descrio da formao e experincia de cada membro da equipe). 1.12 Estimativas de preo e prazo (Estabelecimento do preo e prazo para a realizao dos servios). 1.13 Compatibilidade com normas nacionais e internacionais (Descrio das normas, padres e modelos usados pelo fornecedor). 1.14 Formas de pagamentos

MPS.BR-Guia de Aquisio:2011

41/96

(Descrio da forma de pagamento, por exemplo: nmero de parcelas, valor de cada parcela, entre outras). 1.15 Aspectos legais, como garantia e licenas (Descrio de como o fornecedor tratar os requisitos estabelecidos quanto garantia do produto, suas licenas e distribuies). 1.16 Matriz de atendimento aos requisitos (Relao dos requisitos solicitados e identificao do atendimento a cada um deles, com as informaes adicionais consideradas relevantes. Esta matriz poder ser utilizada para responder aos critrios de seleo formulados no pedido de proposta, indicando o nvel de critrio que est sendo atendido com vistas a obter a respectiva pontuao). 1.17 Contatos (Telefone e e-mail de pessoas para contato).

MPS.BR-Guia de Aquisio:2011

42/96

Anexo D - Contrato CONTRATO DE PRESTAO DE SERVIO N <9999 / 09> (O Contrato de prestao de servios muitas vezes elaborado incluindo apenas clusulas gerais e determinando que o pedido de proposta e a proposta do fornecedor passam a ser parte integrante do contrato. Esta situao tpica para compras pblicas, onde os termos do contrato so publicados juntamente com o pedido de proposta. Por outro lado, nas organizaes em que h maior flexibilidade para tratamento desta questo, o contrato pode ser elaborado a partir da conciliao entre o pedido de proposta e a proposta do fornecedor, introduzindo alguns ajustes possveis a partir do estabelecimento da soluo tcnica e gerencial a ser adotada para atendimento ao problema. O modelo a seguir retrata a primeira situao, onde o pedido de proposta e a proposta do fornecedor serviro como base complementar aos termos gerais relacionados, principalmente por meio das informaes relacionadas a seguir). Informaes do pedido de proposta: Requisitos Termos contratuais Tipo de contrato a ser empregado Multas e penalidades Direitos de distribuio, uso e propriedade do software Garantia do S&SC Termos Tcnicos Procedimentos de confidencialidade Especificao do canal de comunicao Procedimentos para mudanas Procedimentos para tratamento de problemas Lista de S&SC a serem entregues Pontos de controle Prazos estabelecidos Critrios de aceitao do S&SC Requisitos funcionais do software Requisitos de qualidade do software Documentao disponvel Normas e modelos Responsabilidades do projeto Riscos e eventos Identificao do risco Probabilidade de ocorrncia

MPS.BR-Guia de Aquisio:2011

43/96

Impacto no projeto Mitigao dos riscos Plano de contingncia Informaes da proposta do fornecedor: Descrio do entendimento do problema Abordagem tcnica Sugestes de solues Prticas de qualidade Recursos de equipamento, ferramentas e outros Experincia na tcnica e no domnio Experincia da equipe Estimativas de preo e prazo Compatibilidade com normas nacionais e internacionais Formas de pagamentos Aspectos legais, como garantia e licenas Matriz de atendimento aos requisitos Termos gerais que compem o contrato As partes: A < nome da empresa > com sede na < endereo >, no municpio de < nome da cidade >, estado de < nome do estado >, inscrita no CNPJ. sob o n. <nmero de CNPJ > e Inscrio Estadual n < nmero da inscrio estadual >, por seu representante legal, abaixo assinado, doravante designada "CONTRATANTE"; e A < nome da empresa > com sede na < endereo >, no municpio de < nome da cidade >, estado de < nome do estado >, inscrita no CNPJ. sob o n. < nmero de CNPJ > e Inscrio Estadual n < nmero da inscrio estadual >, por seu representante legal, abaixo assinado, doravante designada "CONTRATADA". CONSIDERANDO que a CONTRATANTE e a CONTRATADA firmaram, em < data do contrato >, um Contrato de Prestao de Servios Desenvolvimento de Software, RESOLVEM firmar o presente instrumento particular que se reger pelas seguintes clusulas e condies: 1.Vigncia 1.1. O presente Contrato de Prestao de Servio entra em vigor em < data incio > e termina com a concluso do objeto definido na clusula 2.

2. Objeto

MPS.BR-Guia de Aquisio:2011

44/96

2.1. < Desenvolver ou Adaptar > um software para < funo do software> e treinar as pessoas indicadas pela CONTRATANTE na sua utilizao. 3. Obrigaes da contratante 3.1. A CONTRATANTE fornecer CONTRATADA, sempre que solicitada, os esclarecimentos necessrios ao desenvolvimento do objeto deste contrato. 3.2. A CONTRATANTE garantir o livre acesso dos tcnicos da CONTRATADA, desde que devidamente identificados, s suas dependncias e aos equipamentos, para os fins deste contrato. 4. Obrigaes da contratada 4.1. A CONTRATADA obriga-se a prestar todos os servios descritos na clusula 2 do presente contrato. 4.2. A CONTRATADA obriga-se a fornecer, juntamente com o software, o seu manual de utilizao. 4.3. A CONTRATADA obriga-se a reparar, sem nus para a CONTRATANTE por um perodo de trs meses a contar da implantao, qualquer problema que o software venha a apresentar, em at 24 horas aps a notificao da anormalidade. 4.4. A CONTRATADA obriga-se, sob as penas da lei, a no revelar por quaisquer formas de divulgao quaisquer informaes, dados, materiais, documentos, especificaes tcnicas ou comerciais, inovaes e aperfeioamentos recebidos da CONTRATANTE em decorrncia deste contrato, mesmo aps seu trmino, obrigando-se a utilizar tais informaes nica e exclusivamente com o propsito de realizar os servios objetos deste contrato e somente com as pessoas indicadas ou de conhecimento da CONTRATANTE. 4.5. A CONTRATADA cumprir rigorosamente todas as regras de segurana e normas internas vigentes nos estabelecimentos da CONTRATANTE quando da execuo dos servios. 4.6. A CONTRATADA utilizar adequadamente todos os bens que lhe sejam disponibilizados pela CONTRATANTE para a execuo dos servios. 4.7. A CONTRATADA dever garantir CONTRATANTE por meio de um contrato de manuteno, o suporte do produto aps a sua implantao, bem como a disponibilizao de suas novas verses. 5. Remunerao da contratada 5.1. A CONTRATANTE pagar CONTRATADA o valor correspondente a cada fase do projeto de desenvolvimento do software, mediante a apresentao por parte da CONTRATADA, dos produtos gerados em cada fase, conforme abaixo:. < Fase1 Projeto Lgico do novo sistema > Produtos: 1.....

MPS.BR-Guia de Aquisio:2011

45/96

2.... 3.... Valor desta parcela R$ 9.999,00 < Fase2 ...... > Produtos: 1..... 2.... 3.... Valor desta parcela R$ 9.999,00 5.2. Forma de pagamento. O pagamento previsto na clusula 5.1 do presente contrato, ser efetuado mediante a apresentao pela CONTRATADA da correspondente Nota Fiscal, aps a validao por parte da CONTRATANTE do produto entregue. 6 Consideraes gerais 6.1. Os eventuais custos de despesas de viagem e outros originados por atividades pertinentes aos servios sero de responsabilidade e pagos pela CONTRATANTE. Alm das clusulas j relacionadas, so partes integrantes deste contrato os termos estabelecidos nos documentos Pedido de proposta e Proposta do fornecedor.

6.2.

E por estarem assim, justas e contratadas, assinam a presente Descrio do Projeto em duas vias de igual teor, e para um nico efeito, na presena das testemunhas abaixo. < Cidade, XX/XX/XXX >.

MPS.BR-Guia de Aquisio:2011

46/96

Anexo E Registro de revises 1. Avaliao de processos e software (Relao contendo os produtos de trabalho e os processos do fornecedor avaliados pelo adquirente durante o processo de aquisio; a data da avaliao; o mtodo de avaliao utilizado, por exemplo: validao, auditoria, reviso conjunta, entre outros; o responsvel pela avaliao; e seu resultado como: correto, parcialmente correto e incorreto). Nome do produto /Processo Data da Avaliao Mtodo da Avaliao Responsvel Resultado

2. Avaliao dos aspectos gerenciais (Descrio da avaliao dos aspectos gerenciais do contrato) 2.1 Situao atual do oramento (Descrio do quanto j se gastou e quanto ainda se tem disponvel para o projeto). 2.2 Situao do cronograma (Descrio do tempo gasto at o momento e do prazo para o projeto). 2.3 Dependncias crticas (Descrio de aspectos que precisam ser analisados, por exemplo: novos requisitos, alterao de requisitos, taxas extras, entre outros). 2.4 Riscos identificados (para cada risco) (Descrio dos riscos e suas consequncias). 2.4.1 Identificao do risco (Descrio do tipo de risco, por exemplo: atraso no cronograma, falta de recursos financeiros e humanos, falha de interpretao dos requisitos do software, entre outros). 2.4.2 Data da verificao do risco (Descrio do dia, ms e ano em que o risco foi verificado). 2.4.3 Probabilidade de ocorrncia

MPS.BR-Guia de Aquisio:2011

47/96

(Descrio da probabilidade do risco ocorrer, por exemplo: alta,mdia ou baixa). 2.4.4 - Impacto no projeto (Descrio dos aspectos relevantes que podem afetar o projeto caso o risco ocorra, por exemplo: parar o projeto, falta de verbas para outras atividades, entre outros). 2.4.5 Mitigao dos riscos (Descrio dos procedimentos para amenizar ou eliminar a ocorrncia do risco). 2.4.6 - Plano de contingncia (Descrio dos procedimentos a serem tomados no caso do risco se realizar). 2.5 Problemas encontrados (Descrio de situaes indesejveis, por exemplo: problemas de relacionamento entre os integrantes da equipe). 3. Aes corretivas (Descrio das aes corretivas decorrentes de discrepncias encontradas nas avaliaes dos produtos, dos processos e dos aspectos gerenciais). Descrio Problema do Data da Identificao Soluo Proposta

MPS.BR-Guia de Aquisio:2011

48/96

Anexo F Aspectos relevantes na aquisio de S&SC F.1 Viso geral O principal objetivo deste guia a definio de um processo que possa ser implementado por organizaes que pretendam obter melhorias significativas nas suas aquisies de S&SC. A parte central deste documento, principalmente a seo 4, est voltada a este propsito. Por outro lado, entende-se que as organizaes podero ter dificuldades para transitar de um processo existente, por vezes sem uma estrutura definida, para um modelo mais formal e organizado. Neste sentido, este anexo pretende oferecer algumas orientaes para adquirentes de S&SC que possam ser teis durante o estgio atual destas organizaes, ao longo do perodo de transio e aps a implementao do novo processo. F.2 Problemas comuns na aquisio Prticas de gerenciamento ineficazes so as principais causas de problemas nas aquisies de S&SC. Os problemas so caracterizados pela frequente incidncia de falhas na aquisio de grandes sistemas de software e pelo crescimento dos esforos para manter o custo, o prazo, e para atingir os objetivos definidos. Uma organizao imatura em seus processos de aquisio de S&SC pode levar o projeto ao fracasso, o mesmo podendo ocorrer quando da contratao de uma organizao com processo de desenvolvimento de software imaturo. importante ressaltar que a extenso dos problemas proporcional aos riscos que representam a no concluso do projeto, a operao do sistema no conforme com os requisitos estabelecidos, os riscos representados para vidas humanas quando de seu funcionamento inadequado e as perdas financeiras devido a falhas na sua implementao. Os problemas apontados como os mais comuns durante o processo de aquisio de S&SC, compilados em [ALVES, 2004] so:

Custo do desenvolvimento maior que o oramento previsto; Atraso no prazo de entrega; Resultados insatisfatrios em relao s expectativas do usurio; No-intervencionismo: o cliente no uma parte ativa do projeto aps a assinatura do contrato; Burocracia: excesso de burocracia administrativa para monitorar o contrato e pouco foco nos aspectos tcnicos do projeto; Escopo voltil: o cliente adiciona e altera o escopo e a funcionalidade do projeto com o trabalho em andamento e com prazos e recursos limitados; Fragmentao: membros das equipes do cliente e do Contratado so retirados dos projetos aleatoriamente; Preciosismo: requisitos e imposio de solues complexas no lugar de solues tecnicamente simples; Engenharia: o cliente diz ao fornecedor COMO fazer seu trabalho, e no QUAL o trabalho;

MPS.BR-Guia de Aquisio:2011

49/96

Indicadores: as medidas de progresso e de desempenho so qualitativas, e no quantitativas. Os indicadores de nveis de desempenho so pobres; Comando: com muitos chefes, as decises no so tomadas em tempo; No-envolvimento do usurio final: o ponto de vista do usurio final no incorporado na funcionalidade4 e usabilidade5 do produto; Requisitos pobres: o cliente fornece ao Contratado um conjunto de requisitos incompleto e sem validao; Aquisio incompetente: falhas no entendimento das necessidades particulares da aquisio de software; Falsas promessas: o pessoal de marketing do fornecedor faz promessas ao cliente que a equipe tcnica no pode cumprir; Falta de disciplina: processo de desenvolvimento ad hoc, quando o prazo de entrega do produto est prximo; Expectativas no realistas: cronogramas inexequveis e desconsiderao das limitaes das tecnologias usadas; Recurso inadequado quanto a provimento financeiro, equipe, ferramentas e equipamentos; Ausncia de apoio da alta gerncia da empresa; Ausncia de objetivos claros, conduzindo os membros do projeto para direes no uniformes (no-alinhamento de objetivos); Comunicao ineficiente: ausncia de um canal de comunicao efetivo, fazendo com que as informaes no cheguem at as pessoas em tempo hbil para tomada de alguma medida; Incompetncia: ausncia de perfil tcnico e de liderana apropriados; e Atritos, comprometendo a cooperao de uma das partes envolvidas.

Por outro lado, alguns autores, compilados em [ALVES, 2004], apresentam uma lista de problemas que so considerados clssicos durante o processo de aquisio de S&SC. Observe-se que alguns destes problemas so os mesmos citados anteriormente. Os problemas considerados clssicos so:

Custo maior que o previsto; Alto custo de manuteno; Descumprimento de cronograma; Relao pobre entre cliente e fornecedor;

Capacidade do produto de software de prover funes que atendam necessidades explcitas e implcitas, quando o software estiver sendo utilizado sob condies especificadas. [NBR ISO/IEC 9126-1].
5

Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usurio, quando usado sob condies especificadas. [NBR ISO/IEC 9126-1].

MPS.BR-Guia de Aquisio:2011

50/96

Produtos inexequveis; No atendimento s necessidades do usurio; No atendimento s expectativas do usurio; No atendimentos aos requisitos especificados; Dificuldades de personalizao do software; Perda de controle do projeto; Falta de acompanhamento do projeto; Falta de visibilidade dos processos de Subcontratado; Ciclo de desenvolvimento muito longo; Excesso de retrabalho; Falta de habilidade de prever problemas; Dificuldade na preveno de defeitos; Baixa disponibilidade de recursos humanos; e Alta rotatividade de pessoal.

Para mitigar os problemas apontados acima, so propostas as seguintes aes que devem estar associadas ao processo de aquisio definido neste guia:

Definir e comunicar o objetivo e a viso do projeto a todos os envolvidos; Designar o Gerente de Aquisio que, em ltima instncia, tem a responsabilidade pelo sucesso do processo de aquisio; Ter clara a funo do Patrocinador do projeto que colaborar para seu andamento, definir os limites deste projeto, providenciar o oramento adequado e estvel e conduzir o projeto de forma positiva ou, se necessrio, providenciar seu cancelamento; Adaptar e personalizar as abordagens de aquisio e estratgias de acordo com as caractersticas do projeto; Evitar o excesso de trabalho administrativo, garantindo, no entanto, os seguintes itens: requisitos e compromissos devidamente registrados; documentao das decises importantes; documentao das causas e motivos das decises tomadas; medies quantitativas do progresso do projeto, da qualidade e das mudanas de requisitos; Definir, claramente, qual o objetivo a ser alcanado. Obter requisitos vlidos, estveis, completos e viveis, sempre que possvel. importante, tambm, definir o escopo, para que tanto o cliente quanto o Contratado saibam quando os objetivos foram atingidos e quando o contrato necessita de alteraes e renegociaes; Definir, para cada requisito, como ser a avaliao para a certificao de sua implementao; Garantir que o usurio final seja envolvido na definio dos requisitos e na avaliao do produto;

MPS.BR-Guia de Aquisio:2011

51/96

Informar ao Contratado O QUE est sendo Contratado, e no COMO implementar o objeto da contratao. Efetuar uma reviso conjunta dos requisitos antes do incio do desenvolvimento, com a finalidade de eliminar ambiguidades e mal-entendidos; Selecionar o Contratado cuidadosamente. O Contratado que oferea o menor preo e a programao de prazo mais otimista nem sempre a melhor escolha. Nenhuma prtica de gesto pode alterar o desempenho medocre de uma contratao equivocada; Criar uma cultura de relacionamento amigvel com o Contratado, baseada na confiana, respeito e sempre visando ao benefcio mtuo. As duas ou mais partes envolvidas devem estar cientes de que o sucesso do projeto de responsabilidade de todos os parceiros envolvidos. As partes devem trabalhar como uma equipe, resolver os problemas conjuntamente e evitar a dinmica de mtua atribuio de culpas; Estabelecer um canal efetivo de comunicao e tentar derrubar as barreiras existentes entre as pessoas e os departamentos das organizaes envolvidas no projeto. Assegurar o entendimento mtuo; Evitar buscar sempre obter vantagens do Contratado. Criar uma situao de ganhos mtuos. Cuidar para que o contrato seja benfico e traga vantagens para todas as partes envolvidas, de forma que a assinatura e o comprometimento sejam confortveis para todas as partes; Esperar sempre o melhor, mas agir de forma proativa e se preparar para as eventualidades. Discutir, em conjunto com o(s) Contratado(s), os riscos possveis e formas de mitigao; Escolher sempre as pessoas mais competentes possveis, trein-las e organizar seu plano de trabalho. Providenciar a assistncia e os recursos necessrios; Planejar a manuteno esperada para o software, identificar a forma de suporte e manuteno, antes da elaborao do pedido de proposta; Avaliar os resultados do desenvolvimento do software o mais cedo possvel e com frequncia compatvel com seu porte, antes da avaliao final para aceitao do produto. Essas medidas minimizam a possibilidade de obter um software que no atenda s expectativas do usurio; Efetuar verificaes peridicas. Tomar as providncias necessrias, caso alguma das seguintes questes no seja respondida de forma satisfatria:

O software que est sendo adquirido o mais adequado? O software EST sendo adquirido da forma adequada? O Contratado est desenvolvendo o SOFTWARE ADEQUADO? O Contratado ADEQUADA? est desenvolvendo o software DE FORMA

Ser realista e avaliar novamente as expectativas, medida que o aprendizado sobre o domnio do problema e sua viabilidade tcnica for sendo ampliado com o progresso do projeto. As estimativas e as especificaes iniciais dos

MPS.BR-Guia de Aquisio:2011

52/96

quatro parmetros abaixo mudaro, em algum grau, durante o curso do projeto:


Prazo de entrega; Custo do desenvolvimento; Escopo do software; e Qualidade do software.

Observando-se cuidadosamente os possveis problemas apontados acima e as aes recomendadas para suas respectivas solues, aumentam as possibilidades de que o projeto de aquisio seja finalizado no prazo estabelecido, com os custos previstos e com a implementao das funcionalidades especificadas nos requisitos. F.3 Aquisio de software livre/cdigo aberto (SL/CA) A dinmica do SL/CA o mais recente fenmeno no cenrio da informtica, e que ultrapassando os seus limites tcnicos, gerando um nvel de interesse similar aos dos primeiros momentos da Internet comercial. A conceituao de software livre surgiu em 1983 e os mais de 20 anos de evoluo permitiram ao SL/CA avanar em diversos aspectos: tcnico, poltico-estratgico, de adequao s necessidades dos usurios, qualidade, segurana, entre outros. Esta evoluo devida a um esforo coletivo internacional envolvendo profissionais, usurios e interessados que se dedicam ao aprimoramento, discusso, desenvolvimento, compartilhamento e integrao de SL/CA. Esta dinmica envolve o desenvolvimento de software, a ao de difuso, estmulo e apoio ao uso de SL/CA chegando at a uma viso e ao empresarial marcantemente distinta da atualmente adotada pelas empresas hegemnicas do setor de software. De forma resumida, entende-se por SL/CA todo software que oferece ao usurio, por meio do seu esquema de licenciamento6, a liberdade para uso, reproduo, alterao e redistribuio de seus cdigos fonte. Tambm importante destacar que o modelo de desenvolvimento e o de disponibilidade do software so especficos para o SL/CA. Duas denominaes convivem com esta definio bsica: a de software livre e a de software de cdigo aberto. Os termos so traduo direta dos utilizados em ingls: "free software" e "open source software". Estas denominaes que podem ser atribudas a software contm similaridades e diferenas. Ambas significam mudanas de paradigmas na informtica, seja do ponto de vista do usurio final, do desenvolvedor de software ou de outros agentes direta ou indiretamente relacionados. A principal diferena entre estas denominaes est no foco que os seus proponentes e defensores do ao conceito de software livre/cdigo aberto. Enquanto que as ideias de software livre esto mais vinculadas s questes de garantia e perpetuao das liberdades citadas, as de cdigo aberto esto mais ligadas a

Legalmente, a forma como um usurio pode "relacionar-se" com um software definida atravs de uma licena de uso, que escrita/definida/escolhida pelo produtor do software, e que deve ser aceita e respeitada pelo usurio. A legislao brasileira que trata do assunto a lei n 9.609, de 19/02/1998, artigos 9 e 10.

MPS.BR-Guia de Aquisio:2011

53/96

questes prticas de produo e negcio, como a agilizao do desenvolvimento do software pelas comunidades abertas. Em estudos realizados, percebeu-se que o modelo de disponibilidade do SL/CA pode servir de base para a gerao de negcios. Entretanto, em funo das caractersticas prprias do SL/CA e, em especial, de seu modelo de disponibilidade, a "comercializao" deste no idntica de um software proprietrio. Em funo deste modelo, ao realizar negcios com SL/CA, o cliente/usurio desembolsar valores que esto vinculados diretamente ao trabalho prestado e no ao nmero de licenas adquiridas7. Alm disso, a liberdade de escolha do fornecedor dos servios tambm uma caracterstica apreciada pelos usurios, uma vez que o usurio possui sua cpia do cdigo fonte do software e pode contratar qualquer fornecedor dos servios para os trabalhos desejados. Percebe-se ento que tambm incorreta a percepo de que SL/CA software grtis, sem custos. Os custos existem, entretanto esto associados intrinsecamente aos servios e no ao produto. Em outras palavras, os "fornecedores de SL/CA" so prestadores de servios que, como resultado de seus esforos (de programao, adaptao, integrao, avaliao de opes, entre outros) apresentam um sistema livre, pronto para uso pelos contratantes ou realizam ainda atividades satlites (mas no menos importantes) que permitiro ao contratante (ou aos beneficirios) usufruir o sistema. Com estas caractersticas, avalia-se que o SL/CA permite criar modelos de negcio diferenciados dos que se praticam atualmente na indstria de software, o que pode vir a representar a gerao de novas oportunidades de negcio e a abertura de novos mercados, com a repercusso direta no mercado de trabalho. Algumas empresas centradas em SL/CA adotam mltiplas estratgias para obter o retorno necessrio para suas atividades. Dentre estas estratgias esto os j citados contratos de suporte e manuteno, consultoria e cursos de treinamento e tambm formas mais sofisticadas (aplicveis em alguns casos) como contratos de parcerias, venda de utilidades acessrias, equipamentos e mesmo literatura associada. Embora o fenmeno SL/CA seja recente e esteja na fase de construo tecnolgica, com os vrios atores envolvidos no processo contribuindo para que ocorra tal fechamento, pode-se observar que algumas caractersticas j esto suficientemente delineadas. J possvel observar que existe uma abordagem do SL/CA do ponto de vista de produto, que permite que sejam compreendidos os conceitos fundamentais relacionados ao software em si, do ponto de vista de projeto de SL/CA que uma organizao virtual dedicada manuteno de um produto de SL/CA e do ponto de vista de Processo de Desenvolvimento, com prticas e conceitos estabelecidos. Considerando ainda que existam modelos de negcio j estabelecidos para o relacionamento cliente e fornecedor de SL/CA, pode-se concluir que j existe oferta e demanda por S&SC em SL/CA. Diante do cenrio exposto, importante que as organizaes ao considerar a aquisio ou fornecimento de S&SC em um modelo de SL/CA, se preocupem em

Ou outra variante de licenciamento de software proprietrio, comentada em nota anterior.

MPS.BR-Guia de Aquisio:2011

54/96

realizar as devidas adaptaes e modificaes em seus processos de aquisio, de forma que estes possam acomodar as caractersticas particulares desta nova forma de fornecimento e aquisio. Para um aprofundamento nas questes relativas a SL/CA, podem ser pesquisadas a Open Source Initiative (OSI), disponvel em www.opensource.org e Free Software Foundation (FSF), disponvel em www.fsf.org e no Brasil o site www.softwarelivre.org. F.4 Aquisio e a Engenharia de Software baseada em componentes Uma possvel abordagem para aquisio de software est relacionada utilizao de componentes. Ainda que seja possvel personalizar o processo descrito neste guia, visando a aquisio de componentes de software, importante que se levem em conta as consideraes a seguir. De acordo com [SAMETINGER,1997], o componente de software deve: ser autocontido, ser identificvel, ter funcionalidade (descrever e/ou desempenhar funes especficas), ter interfaces, ter documentao (indispensvel para o reso) e ter status de reso definido. Outra definio, que auxilia o entendimento do componente como um produto, numa viso comercial, sendo desenvolvido por produtores (fornecedores) e adquirido por consumidores (desenvolvedores), como um artefato para composio de outros sistemas, colocada por [DSouza, 1998]: um componente (cdigo) um pacote coerente de implementao que pode ser desenvolvido e distribudo independentemente, prov interfaces explcitas e bem especificadas, define interfaces que ele precisa de outros componentes, e pode ser combinado com outros componentes pela configurao de suas propriedades, sem a necessidade de modificao. Um novo desafio para o desenvolvimento baseado em componentes o chamado problema da confiana no componente. O problema est na dificuldade em saber se o componente faz o que realmente deveria fazer. Um consumidor muitas vezes precisa decidir entre vrios componentes, de fornecedores distintos, por aquele adequado composio do novo sistema. O fornecedor de um componente pode medir as caractersticas de qualidade de um componente como uma unidade, mas no pode prever todos os seus futuros contextos de reutilizao e garantir sua adequao. Esta questo especialmente mais difcil quando se trata de componentes desenvolvidos por terceiros ou de componentes do tipo COTS - Commercial Off-The-Shelf (desenvolvidos comercialmente, disponveis em prateleiras), os quais normalmente so distribudos sem o cdigo fonte. Todavia, esta questo tambm est presente para componentes desenvolvidos na prpria organizao, onde a falta de documentao e a dificuldade de comunicao das equipes de desenvolvimento podem produzir um efeito similar. A garantia de sucesso do desenvolvimento baseado em componentes depende da qualidade dos componentes de software. Os desenvolvedores precisam saber se o componente confivel e adequado ao sistema [VOAS, 1998]. Muitos componentes de software so oferecidos como caixas-pretas, como objetos executveis, aos quais as licenas no permitem acesso aos cdigos fontes (ou licenciados a preos proibitivos). Ento, como saber se um determinado componente adequado para

MPS.BR-Guia de Aquisio:2011

55/96

integrar um sistema baseado em componentes? Como prever se realizar a funo necessria ao encaixar-se na arquitetura? Ou, ainda, se preenche os requisitos desejados com a qualidade adequada? Se considerarmos componentes como pacotes de software, possvel utilizar os conceitos contidos na NBR ISO/IEC 121198 que trata dos seus requisitos de qualidade e teste. Estes conceitos podem ser de grande valia para os consumidores de componentes ou pacotes de software. Eles tratam de aspectos importantes que podem ser abordados durante sua aquisio. Portanto, ao adquirir um componente ou pacote de software o consumidor deve verificar: 1 - Descrio do produto: um documento contendo as propriedades e o principal propsito do pacote de software ou componente, ajudando o comprador na avaliao de sua adequao antes de adquiri-lo. Esta descrio dever conter: Identificao nica do documento, Funcional ou Informaes do Produto; por exemplo: Descrio

Identificao do produto contendo pelo menos o nome e a sua verso ou data; O nome e endereo de pelo menos um dos fornecedores; Tarefas que podem ser realizadas pelo produto; Requisitos do sistema, como: unidade de processamento, tamanho da memria principal, tipos e tamanhos de armazenamentos perifricos, equipamentos de entrada e sada, ambiente de rede, software do sistema operacional e outros tipos de software; Interfaces com outros produtos; Itens a serem entregues; Informao de instalao (se pode ou no ser executada pelo comprador); Informao de suporte (se haver ou no suporte para a operao do produto); Informao de manuteno (se haver ou no manuteno do produto e o que ser includo nela); Viso geral das funcionalidades do produto, os dados necessrios e as facilidades oferecidas; Valores limites suportados pelo produto; Informaes de segurana para prevenir acesso no autorizado a programas ou dados;

Esta norma foi atualizada pela norma internacional ISO/IEC 25051, porm os conceitos relacionados nesta seo so semelhantes e foram mantidos para manter a compatibilidade com o texto relacionado s referncias bibliogrficas citadas.

MPS.BR-Guia de Aquisio:2011

56/96

Informaes de confiabilidade, como: verificar se as entradas so plausveis, proteo contra erros de usurios e recuperao de erros; Informaes de usabilidade, como o tipo de interface usada com o usurio, conhecimento requerido para o uso do produto, se o produto pode ser adaptado pelo usurio e em que condies, e procedimentos usados para a proteo contra cpias; Informaes relativas eficincia do produto, como tempo de resposta; Informaes quanto manutenibilidade9; e Informaes quanto portabilidade10.

2 - Documentao do usurio: um documento contendo as informaes necessrias para o uso do produto. Todas as funes citadas na descrio do produto e suas formas de acionamento pelo usurio devem estar descritas neste documento. Este documento deve ser completo, correto, consistente e inteligvel. 3 Informaes relativas a programas e dados: se a instalao puder ser realizada pelo comprador ento necessrio um manual de instalao. Os programas e os dados devem corresponder e no apresentar contradies com a descrio do produto e documentao do usurio. 4 Instrues para teste: estas instrues descrevem como um produto deve ser testado com relao aos requisitos de qualidade. Estes testes incluem tanto o teste para as propriedades requeridas quanto o teste para as propriedades prometidas pela descrio do produto. Eles incluem o teste de inspeo dos documentos que fazem parte do produto como: descrio do produto, documentao do usurio, programas e dados, assim como os testes de caixa-preta para avaliar o comportamento de seus programas e dados. A qualidade de componentes de software fundamental para o sucesso de aplicaes baseadas em componentes. Segundo [Simo, 2002], as caractersticas e subcaractersticas de qualidade abordadas pela NBR ISO/IEC 9126-1 tambm podem ser utilizadas como metas a serem atingidas no desenvolvimento, na seleo e na aquisio de componentes. importante ressaltar, para aqueles que desejam adquirir componentes para desenvolver software com reso, a existncia da IEEE Std 1517:1999 como uma norma especfica para o desenvolvimento para reso e que uma extenso da ISO/IEC 12207.

Capacidade do produto de software de ser modificado. As modificaes podem incluir correes, melhorias ou adaptaes do software devido a mudanas no ambiente e nos seus requisitos ou especificaes funcionais. [NBR ISO/IEC 9126-1].
10

Capacidade do produto de software de ser transferido de um ambiente para outro.

[NBR ISO/IEC 9126-1].

MPS.BR-Guia de Aquisio:2011

57/96

Anexo G - Funes no projeto de aquisio G.1 Viso geral Uma boa equipe composta por pessoas experientes e eficientes a chave para o sucesso de um projeto. Os projetos de aquisio de software possuem diferentes caractersticas. Alguns projetos so pequenos, de rpida finalizao e de fcil compreenso, enquanto que outros tm caractersticas opostas. Cada organizao deve desenvolver sua prpria maneira de trabalhar, e cada projeto deve considerar suas prprias metodologias, levando em conta a cultura, a posio, a criticidade e a tecnologia disponvel. Para conseguir um processo de aquisio efetivo, que apresente bons resultados, necessrio que se empregue um nvel adequado de formalidade aos processos, de acordo com as caractersticas do projeto em questo. Cada projeto, dependendo de suas caractersticas, apresenta um fluxo que deve ser gerenciado pelo processo de gesto da aquisio de S&SC. Esse fluxo representa a arquitetura que dever ser implementada quando da operacionalizao do projeto de aquisio. Para a implementao desta arquitetura necessrio que algumas funes sejam executadas e que pessoas sejam designadas para cada uma delas dependendo do porte do projeto e de sua complexidade. Neste anexo ser apresentada uma possvel classificao dos diferentes tipos de funes necessrias para o sucesso de um projeto de aquisio de S&SC. Note-se que uma pessoa pode executar mais de uma funo. As funes podem ser divididas em categorias, na verdade quatro categorias, sendo elas: funes do patrocinador, funes de gesto, funes de assistncia ou suporte e funes executivas, dependendo de suas caractersticas conforme definidas abaixo: Funes do patrocinador so responsveis pela obteno de provimento financeiro para o projeto e tm o poder de decidir sobre seu prosseguimento ou cancelamento. as funes do patrocinador, neste contexto, so: patrocnio, colaborao com o cliente e gesto de produto; Funes de gesto so funes de planejamento, gerncia, acompanhamento e administrao do projeto. As funes de gesto so: gesto da aquisio, gesto tcnica, gesto de contrato e administrao; Funes de assistncia ou suporte so executadas por diferentes especialistas; so responsveis por orientaes especficas e suporte ao Contratado durante a evoluo do projeto. as funes de assistncia ou suporte so: especialista em aquisio, especialista tcnico, especialista no domnio do produto, especialista em assuntos legais, tradutor, usurio final, equipe de manuteno e suporte, verificao e validao independente, engenharia de sistemas e assistncia tcnica; Funes executivas so as funes exercidas por parte do contratado. as funes executivas so: contratado, contratado colaborador, subcontratado e fornecedor complementar;

MPS.BR-Guia de Aquisio:2011

58/96

G.2 Funes do patrocinador As funes do patrocinador so executadas por pessoas que representam a organizao e tm poder de iniciar e cancelar o projeto de aquisio. As funes do tipo patrocinador so: patrocinador, cliente colaborador e gerente de produto. G.2.1 Patrocinador Inicia e acompanha o projeto de aquisio com entusiasmo. Tem o poder de cancelar o projeto, caso seu custo seja maior que o benefcio que agregar organizao aps sua finalizao. As responsabilidades do patrocinador do projeto so: definir e comunicar os objetivos e a viso do projeto; providenciar um oramento adequado e colocar os limites financeiros e outros para o projeto; e escolher um gerente que tenha responsabilidade pelo sucesso do projeto. O patrocinador deve ser muito cuidadoso e no interferir na forma como o gerente escolhido executa a gesto do projeto. G.2.2 Cliente colaborador Um projeto de aquisio pode ser um projeto de vrios fornecedores ou cofornecedores, com um grande nmero de organizaes-cliente envolvidas. o cliente colaborador o patrocinador de um outro projeto cuja colaborao necessita ser coordenada com os outros patrocinadores. G.2.3 Gerente de produto em alguns casos, o software parte de um grande sistema em aquisio, onde o gerente de produto executa a funo de patrocinador perante o sistema. G.3 Funes de gesto So funes executadas por pessoas do cliente responsabilizadas pela gesto, acompanhamento e administrao dos procedimentos do projeto de aquisio de software. Os diferentes tipos de funes de gesto so: gerente de aquisio, gerente tcnico, gerente de contrato e administrador. G.3.1 Gerente de aquisio indicado pelo patrocinador e responsvel pelo sucesso do projeto. O gerente de aquisio tem a palavra final sobre a execuo do projeto. Suas tarefas e responsabilidades so: adaptar e personalizar a estratgia de aquisio de acordo com as caractersticas do projeto; planejar o projeto e executar conforme o planejado; refazer o planejamento durante o progresso do projeto; gerenciar os riscos e resolver os problemas; contratar e organizar as pessoas da equipe de aquisio; executar as atividades de treinamento e formao de equipe; motivar e encorajar as pessoas, tornar o caminho de cada elemento mais fcil e apoiar a equipe; selecionar e prestar suporte aos fornecedores; negociar e assinar acordos com o contratado e com os contratados de suporte; gerenciar a relao entre o contratado e a organizao, tomando como referenciais valores tais como moral, confiana, comunicao e colaborao; deixar claro ao fornecedor qual o escopo do software, de forma a garantir que tanto o fornecedor quanto o gerente possam identificar quando ele atingido; gerenciar o oramento do projeto dentro do limite imposto pelo patrocinador; coordenar o trabalho para o acompanhamento do progresso do projeto; tornar o patrocinador ciente desses resultados; e executar verificaes peridicas. Dever tambm executar as aes necessrias caso as

MPS.BR-Guia de Aquisio:2011

59/96

respostas s seguintes questes no forem satisfatrias: O software correto est sendo adquirido? O software est sendo adquirido da forma correta? O fornecedor est desenvolvendo o software da forma correta? Deve, ainda, fazer o balano entre o prazo de entrega, o custo total, o escopo do produto, a qualidade do produto, para verificar os desvios com relao s estimativas e s especificaes, quando ocorrerem; coordenar o trabalho de avaliao e aceitao do produto; e preparar o suporte ps-contrato e a manuteno do produto. G.3.2 Gerente tcnico Para grandes projetos onde existe demanda de alta qualidade e tcnicas complexas, por exemplo, software de misso crtica, o gerente de aquisio pode delegar as responsabilidades pelos requisitos e qualidade para o gerente tcnico. G.3.3 Gerente de contrato Para projetos com muitas organizaes envolvidas, ou projetos onde a administrao do contrato grande, o gerente de aquisio pode delegar as responsabilidades pela gesto do contrato para o gerente de contrato. G.3.4 Administrador O limite do administrador depende do tamanho e do tipo do projeto. O cuidado a ser tomado para garantir uma boa administrao, e no uma burocratizao desnecessria das funes administrativas. Um membro da equipe de aquisio executa a funo de administrao, mas em alguns projetos uma pessoa especfica deve ser responsabilizada pela funo. As responsabilidades da funo do administrador incluem a manuteno da configurao e gesto de mudanas nos documentos do projeto, como o contrato, a especificao de requisitos, planejamento do projeto, lista de riscos e outros; documentar e arquivar as correspondncias, tempo de reunio e decises; administrar o pagamento e dar suporte ao contratado; e documentar e arquivar as medidas de progresso, qualidade e mudanas de requisitos. G.4 Funes de assistncia ou suporte A funo de assistncia executada por diferentes especialistas e contratados de suporte, que podem assistir e orientar a gerncia, a direo e as funes executivas. As funes so: especialista em aquisio, especialista tcnico, especialista de domnio, especialista legal, tradutor, usurio final, equipe de manuteno e suporte, verificao e validao independente, engenharia de sistemas e assistncia tcnica. G.4.1 Especialista em aquisio Um especialista em aquisio pode ser usado para orientar como planejar e executar um projeto de aquisio, definir o veculo contratual, selecionar e treinar a equipe em gesto de aquisio de software. G.4.2 Especialista tcnico Um Especialista tcnico pode ser usado para avaliar os requisitos e fazer uma estimativa independente de custo e prazo. O especialista tcnico pode ser usado para revisar os documentos tcnicos e auditar o conhecimento tcnico e a capacidade do contratado. O contratado pode usar o especialista tcnico para reas nas quais no tenha competncia estabelecida.

MPS.BR-Guia de Aquisio:2011

60/96

G.4.3 Especialista de domnio O especialista de domnio no , necessariamente, um especialista tcnico, mas conhece profundamente o campo no qual o software ser usado. O especialista de domnio pode ser usado para desenvolver e validar os requisitos para o software. Outra tarefa para esse especialista pode ser desenvolver o treinamento para o usurio do software. G.4.4 Especialista legal O especialista legal essencial para aconselhar como o contrato deve ser escrito e informar quais so as leis e regulamentaes atuais e outros assuntos concernentes ao projeto, como direito de propriedade intelectual, patentes, licenas, garantias, direito de reproduo e outros. O especialista legal pode, tambm, auxiliar durante uma disputa e rompimento com o contratado. O uso de um especialista legal com conhecimento especfico na rea de software, especialmente em projetos internacionais, fundamental para o projeto de aquisio. G.4.5 Tradutor O tradutor uma funo que pode ser executada por uma pessoa capaz de traduzir termos tcnicos em termos legais, e vice-versa. Esta funo pode ser til na especificao de requisitos e transferncia de requisitos para a equipe tcnica do contratado. A pessoa deve ter o perfil para traduzir as necessidades do cliente em algo que o contratado possa usar para construir o sistema. G.4.6 Usurio final O usurio final a razo da existncia do software, exceto se o software no interage diretamente com usurios humanos. Dessa forma, imperativo envolver o usurio final na especificao dos requisitos para o software, na avaliao da interface com o usurio e na avaliao das funcionalidades do produto de software. G.4.7 Equipe de manuteno e suporte Tem como tarefa principal manter o software em execuo, fazer evolues, corrigir defeitos e adicionar novas facilidades, assim como fornecer suporte tcnico para o usurio final. importante solicitar as sugestes das equipes de manuteno e suporte sobre os requisitos necessrios ao software, para que ele seja de fcil manuteno e verificao de defeitos. Elas devem, tambm, ser envolvidas na avaliao das capacidades de manuteno, verificao e resoluo de defeitos do software e na reviso da documentao, para verificar se elas contm todas as informaes necessrias ao seu trabalho. A equipe de manuteno e suporte deve ser envolvida o mais cedo possvel no projeto, para promover e facilitar a discusso de como a organizao de manuteno e suporte pode ser organizada, para proporcionar uma transio suave do software, quando de sua entrega para a manuteno e suporte, com a respectiva manuteno da gerncia de configurao. Esta funo pode ser executada pela prpria organizao ou pode ser terceirizada. G.4.8 Verificao e validao independente Funo que pode ser contratada pelo cliente para a execuo de uma avaliao tcnica profunda do software entregue. Este expediente recomendado quando o software afeta a sade pblica ou a vida de pessoas, ou quando um grande volume de dinheiro est envolvido e pode ser perdido quando do funcionamento inadequado

MPS.BR-Guia de Aquisio:2011

61/96

do produto. A verificao e validao independente podem aumentar o custo do projeto significativamente. G.4.9 Engenharia de sistemas e assistncia tcnica Quando o cliente ou o fornecedor no possui o recurso adequado para uma determinada especialidade, necessria uma contratao suplementar para suprir essa deficincia. Dessa forma, a empresa contrata a engenharia de sistemas e assistncia tcnica. Este servio pode compreender desde o planejamento do projeto at o teste, medies e garantia da qualidade. O uso de contratados deve ser considerado para as seguintes reas: riscos tcnicos, testes independentes, gesto de suporte e integrao. G.5 Funes executivas Estas funes so executadas por representantes do contratado, ou seja, quem est desenvolvendo o produto de software em questo. Elas so: contratado, colaborador contratado, subcontratado e fornecedor. G.5.1 Contratado O contratado pode ser nico ou o primeiro contratado, no caso do uso do trabalho colaborativo de vrios contratados. O contratado deve ser escolhido cuidadosamente, pois o contratado com a oferta de preos mais baixa e as programaes mais otimistas de prazo e custos nem sempre a melhor escolha. Nenhuma prtica de gesto pode compensar o prejuzo de um contratado inadequado. Uma vez selecionado, o contratado deve ser visto como um membro da equipe, e no como um adversrio. As responsabilidades do contratado so: Desenvolver e entregar o produto de software requisitado. Quando o projeto cancelado, deve ser entregue ao cliente o produto do desenvolvimento at o momento do cancelamento; Demonstrar que as capacidades tcnicas e de gesto so adequadas para o desenvolvimento do software. Caso sejam utilizados subcontratados ou contratados de suporte, obrigatrio que tambm estes demonstrem suas competncias e capacidades; 11 Apresentar um plano de trabalho e uma estrutura de trabalho, WBS , viveis e com estimativas realistas de custos e prazos para o projeto. Mostrar ao cliente, regularmente, o progresso do desenvolvimento e a distncia at a sua finalizao; Certificar-se de que os requisitos foram corretamente entendidos; Incentivar o desenvolvimento de uma cultura efetiva, funcional e cooperativa no relacionamento com o cliente, e que seja construda com base em confiana e respeito. As partes devem compreender que so mutuamente responsveis pelo sucesso do projeto e devem abster-se das tentativas de obter vantagens, uma sobre a outra. As partes envolvidas devem trabalhar como uma equipe, resolver os problemas conjuntamente e evitar a dinmica de imputao de culpas mtuas; Avisar o cliente, com prontido e transparncia, sobre problemas no previstos anteriormente e mudanas de prazos;

11

Work Breakdown Structure

MPS.BR-Guia de Aquisio:2011

62/96

Discutir, rever e mitigar os riscos conjuntamente.

G.5.2 Colaborador contratado Na existncia de mais de um contratado, a colaborao entre eles deve ser coordenada. Uma forma eleger um dos contratados como primeiro contratado, com a responsabilidade de coordenar o trabalho dos colaboradores contratados. G.5.3 Subcontratado O contratado pode usar subcontratados para entregar partes de um software. A competncia e a capacidade do subcontratado devem ser avaliadas, e o cliente tem o direito de escolher o mais adequado. Se o contratado for usar subcontratados, assegure que eles sejam envolvidos o mais cedo possvel no projeto. G.5.4 Fornecedor complementar Pode ser necessrio contratar fornecedores de COTS e hardware durante o projeto.

MPS.BR-Guia de Aquisio:2011

63/96

Anexo H - Normas brasileiras e ISO/IEC para avaliao de produto de software H.1 Descrio geral O processo de aquisio de software envolve a avaliao do produto antes de sua aceitao. O Brasil vem atuando na produo de normas brasileiras para avaliao da qualidade de produto de software, baseadas nas normas da ISO/IEC. Como consequncia, j esto disponveis e em uso no pas diversas normas de apoio a este processo, conforme relacionadas a seguir. H.2 Avaliao utilizando a ABNT NBR ISO/IEC 25051 A ABNT NBR ISO/IEC 25051 estabelece como um produto de software comercial de prateleira (COTS) deve representar seus requisitos de qualidade e fornece instrues de como testar estes produtos de software em relao aos requisitos definidos. Adicionalmente fornece instrues para a avaliao de conformidade de produto de software comercial de prateleira (COTS). Seu escopo refere-se a pacote de software, na forma oferecida no mercado e no aos processos de desenvolvimento e fornecimento de software. O pacote de software pode ser testado ou a ter sua qualidade avaliada com relao : Descrio do produto Um documento que fornece a descrio geral do produto, bem como estabelece declaraes relacionadas s caractersticas de qualidade do produto de software e de qualidade em uso, com o propsito de orientar potenciais compradores na avaliao da adequao do produto antes de compr-lo. Caso o produto de software no disponha da descrio do produto, isto considerada uma no-conformidade maior. Documentao do usurio O conjunto completo de documentos, disponvel em forma impressa ou no, que fornecido para a aplicao do produto de software e tambm como parte integral deste produto. Esta documentao deve seguir uma srie de recomendaes que assegurem a sua qualidade. Requisitos de qualidade para o software Requisitos esperados para o produto de software que estejam em conformidade com o estabelecido na descrio do produto, na documentao do usurio e com alguns requisitos tpicos para produtos de software comerciais de prateleira (COTS). A Figura 2 mostra a estrutura bsica do contedo da norma, indicando os requisitos de qualidade para as partes de um pacote de software e tambm as atividades de teste para um pacote de software.

MPS.BR-Guia de Aquisio:2011

64/96

ISO/IEC 25051 Requisitos de qualidade de produto de software comercial de prateleira (COTS) e instrues para teste

Requisitos de qualidade
Descrio produto Documentao usurio Software

Requisitos da Documentao de teste


Gerais Plano de teste Descrio de testes Resultados de testes

Instrues para avaliao de conformidade


Princpios gerais Pr-requisitos Atividades Processo de terceira-parte Relatrio de avaliao Avaliao de acompanhamento

Figura 2 Estrutura da norma ABNT NBR ISO/IEC 25051 Esta norma bastante utilizada internacionalmente, principalmente na Europa, sendo tambm referncia em diversas avaliaes efetuadas aqui no Brasil, por meio de mtodos de avaliao como, por exemplo, o MEDE-PROS Mtodo de Avaliao de Qualidade de Produto de Software [COLOMBO, 2004]. H.3 Avaliao com as sries ABNT NBR ISO/IEC 9126 e 14598 12 As sries de normas ABNT NBR ISO/IEC 9126 e 14598 dedicam-se avaliao da qualidade de qualquer tipo de produto de software. As normas destas sries definem um Modelo de qualidade para produtos de software e um Processo de avaliao da qualidade de software. A seguir so apresentados, resumidamente, estes conjuntos de normas. Modelo de qualidade ABNT NBR ISO/IEC 9126-1 A norma ABNT NBR ISO/IEC 9126-1 define um Modelo de Qualidade, que utilizado como referncia para o processo de avaliao da qualidade de produto de software, e est subdividido em duas partes: Modelo de Qualidade para caractersticas externas e internas; e Modelo de Qualidade para qualidade em uso.

12

A ISO/IEC est revendo estas normas referentes avaliao de produto de software, constituindo o modelo denominado SQuaRE (Software Quality Requirements and Evaluation), que apresenta uma evoluo dos conceitos representados nas sries de normas que esto sendo substitudas. Algumas destas normas j esto publicadas pela ISO e o modelo geral do SQuaRE pode ser encontrado na norma ABNT NBR ISO/IEC 25000 - Engenharia de software - Requisitos e avaliao da qualidade de produtos de software (SQuaRE) - Guia do SQuaRE.

MPS.BR-Guia de Aquisio:2011

65/96

O Modelo de Qualidade para caractersticas externas e internas classifica os atributos de qualidade de software em seis caractersticas (funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade) as quais so, por sua vez, desdobradas em subcaractersticas. As subcaractersticas podem ser desdobradas em mais nveis, que caracterizam os atributos de qualidade. No Modelo de Qualidade para qualidade em uso, os atributos so classificados em quatro caractersticas: eficcia, produtividade, segurana e satisfao. A qualidade em uso a capacidade do produto de software de permitir a usurios especficos atingir metas especificadas com eficcia, produtividade, segurana e satisfao em um contexto de uso especificado. Exemplos de mtricas A ISO/IEC desenvolveu trs relatrios tcnicos internacionais, como documentos de apoio ao processo de definio de requisitos e avaliao da qualidade de produto de software. Estes documentos ainda no foram traduzidos pela ABNT. ISO/IEC TR 9126-2 Este relatrio tcnico define o conceito de mtricas externas13 e apresenta um conjunto de mtricas que podem ser utilizadas para definio e avaliao de qualidade de produto de software. Na parte comum aos trs documentos de mtricas so identificadas propriedades desejveis para a seleo de uma mtrica para produto de software. ISO/IEC TR 9126-3 Este relatrio tcnico tem formato semelhante ao ISO/IEC 9126-2 fornecendo, no entanto, um conjunto de mtricas internas14. ISO/IEC TR 9126-4 Este relatrio tcnico tem partes comuns com os dois anteriores, fornecendo um conjunto de mtricas de qualidade em uso, alm de apresentar um exemplo de processo de avaliao da qualidade em uso. Avaliao da qualidade de produto de software ABNT NBR ISO/IEC 14598-1 Esta norma apresenta toda a estrutura de funcionamento da srie de normas para avaliao da qualidade dos produtos de software, alm de definir os termos tcnicos utilizados nesse modelo. Fornece tambm os conceitos e o funcionamento do processo de avaliao da qualidade de qualquer tipo de software, para utilizao por desenvolvedores (incluindo gerentes, analistas de requisitos, projetistas de software, implementadores e equipe de garantia da qualidade), por adquirentes e por avaliadores de software independentes. De maneira geral, pode ser utilizada por pessoas envolvidas no desenvolvimento, padronizao e uso de tecnologia de avaliao.

13 14

Mtricas relacionadas ao comportamento do sistema que inclui o software.

Mtricas relacionadas s propriedades estticas do software como, por exemplo, documentao, cdigo fonte, lista de requisitos, entre outras.

MPS.BR-Guia de Aquisio:2011

66/96

ABNT NBR ISO/IEC 14598-2 Esta norma apresenta requisitos, recomendaes e orientaes para uma funo de suporte ao processo de avaliao dos produtos de software. O suporte est relacionado ao planejamento e gerenciamento de um processo de avaliao de software e a tecnologia necessria, incluindo: desenvolvimento, aquisio, padronizao, controle, transferncia e realimentao do uso de tecnologias de avaliao no mbito da organizao. ABNT NBR ISO/IEC 14598-3 Esta norma destina-se ao uso durante o processo de desenvolvimento e manuteno de software, enfocando a seleo e registro de indicadores que possam ser medidos e avaliados a partir dos produtos intermedirios, obtidos nas fases do desenvolvimento de sistemas, com o objetivo de prever a qualidade do produto final a ser desenvolvido, de modo a orientar a tomada de decises tcnicas e gerenciais ao longo do processo de desenvolvimento. ABNT NBR ISO/IEC 14598-4 Esta norma direcionada para adquirentes de software e estabelece um processo sistemtico para avaliao de: produtos de software de prateleira, produtos de software sob encomenda ou, ainda, modificaes em produtos j existentes. O propsito da avaliao pode ser a comparao entre diversas alternativas de produtos existentes no mercado, ou a tentativa de garantir que um produto desenvolvido ou modificado sob encomenda atenda aos requisitos inicialmente especificados. A norma considera o Modelo de Qualidade da ABNT NBR ISO/IEC 9126-1 e utiliza o processo de avaliao definido genericamente na ABNT NBR ISO/IEC 14598-1. ABNT NBR ISO/IEC 14598-5 Esta norma fornece orientaes para a implementao prtica de avaliao de produto de software, quando diversas partes necessitam entender, aceitar e confiar em resultados de avaliao. Normalmente utilizada considerando o Modelo de Qualidade descrito na norma ABNT NBR ISO/IEC 9126-1. O processo descrito define as atividades necessrias para analisar os requisitos de avaliao de modo a especificar, projetar e executar as atividades de avaliao e para se obter a concluso sobre avaliao de qualquer tipo de produto de software. ABNT NBR ISO/IEC 14598-6 Esta norma define a estrutura e o contedo da documentao a ser usada na descrio dos Mdulos de Avaliao. Explica como desenvolver mdulos de avaliao e como valid-los. Um Mdulo de Avaliao um conjunto de instrues e dados usados para avaliao. Ele especifica os mtodos de avaliao aplicveis para avaliar as caractersticas de qualidade. Define tambm os procedimentos elementares de avaliao e o formato do relatrio de apresentao dos resultados das medies resultantes das aplicaes das tcnicas. O uso de mdulos de avaliao produzidos e validados, conforme a norma, deve garantir que as avaliaes de software possam ser repetidas, reproduzidas e imparciais. Em resumo, as Normas das sries 9126 e 14598 podem ser utilizadas em complementao uma outra, de acordo com o objetivo da avaliao. A Norma ABNT NBR ISO/IEC 9126-1 estabelece um Modelo de Qualidade, enquanto que os

MPS.BR-Guia de Aquisio:2011

67/96

relatrios tcnicos ISO/IEC 9126-2, ISO/IEC 9126-3 e ISO/IEC 9126-4, fornecem exemplos de mtricas de qualidade de software. A Norma ABNT NBR ISO/IEC 14598-1 contm conceitos de como avaliar a qualidade de software e define um modelo de processo de avaliao genrico. As normas ABNT NBR ISO/IEC 14598-2 e ISO/IEC 14598-6, estabelecem itens necessrios para o suporte avaliao e as normas ABNT NBR ISO/IEC 14598-3, ABNT NBR ISO/IEC 14598-4 e ABNT NBR ISO/IEC 14598-5 estabelecem processos de avaliao especficos para desenvolvedores, adquirentes e avaliadores de software, respectivamente. O relacionamento entre elas pode ser observado na Figura 3.

Recursos e Ambiente

Processo de Avaliao

Produto de Software

Efeitos do Produto de Software

Suporte avaliao

Processo de avaliao

Mtricas internas 14598-1

Mtricas Externas

Mtricas de qualidade em uso

14598-2 14598-6

14598-3 9126-1 14598-4 14598-5 9126-3 9126-2 9126-4

Figura 3 Relacionamento entre as sries 9126 e 14598

H.4 A srie de normas SQuaRE O grupo de trabalho WG6, do Subcomit de Sistemas e Software (SC7) da ISO/IEC, que o responsvel pela elaborao de normas internacionais que tratam da especificao, medio e avaliao da qualidade de produtos de software, vem desenvolvendo um trabalho de reviso das normas das sries ISO/IEC 9126 e ISO/IEC 14598, de especificao e avaliao da qualidade de produto de software, resultando num novo modelo denominado SQuaRE, que um acrnimo de Software Quality Requirements and Evaluation. A definio da arquitetura de normas SQuaRE teve incio em 1999 e vem orientando a reviso das normas j publicadas pela ISO, bem como a criao de novas normas que atendem aos requisitos do mercado e a evoluo da Engenharia de Software. O ncleo principal do SQuaRE composto de quatro divises de normas e uma sequncia prevista para extenso do modelo: ISO/IEC 2500n Diviso Gesto da Qualidade, ISO/IEC 2501n Diviso Modelo de Qualidade,

MPS.BR-Guia de Aquisio:2011

68/96

ISO/IEC 2502n Diviso Medio da Qualidade, ISO/IEC 2503n Diviso Requisitos de Qualidade, ISO/IEC 2504n Diviso Avaliao da Qualidade, e ISO/IEC 2505n ISO/IEC 25099 Extenso do SQuaRE.

Essas divises so compostas de normas, harmonicamente integradas, que detalham os tpicos relacionados especificao e avaliao da qualidade de produtos de software, conforme breve descrio a seguir. Diviso Gesto da Qualidade ISO/IEC 25000 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE (publicada pela ISO) ABNT NBR ISO/IEC 25000 - Engenharia de software Requisitos e avaliao da qualidade de produto de software (SQuaRE) Guia do SQuaRE (publicada pela ABNT) Esta norma fornece orientaes sobre o uso da srie de normas SQuaRE, propiciando uma viso geral do contedo do SQuaRE, de seus modelos de referncia e definies, bem como do relacionamento entre os documentos da srie. ISO/IEC 25001 - Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Planning and management (publicada pela ISO) ABNT NBR ISO/IEC 25001 - Engenharia de software Requisitos e avaliao da qualidade de produto de software (SQuaRE) Planejamento e gesto (publicada pela ABNT) Esta norma fornece requisitos e recomendaes para uma organizao responsvel por implementar e gerenciar a especificao de requisitos de qualidade do produto de software e pelas atividades de avaliao da qualidade de software, provendo tecnologia, ferramentas, experincias e habilidades de gesto. Diviso Modelo de Qualidade ISO/IEC 25010 Systems and software engineering Software product Quality Requirements and Evaluation (SQuaRE) Quality models for software product quality and systems quality in use (publicada pela ISO) Esta norma define um modelo de qualidade de produto de software, composto de caractersticas e subcaractersticas que se manifestam externamente quando o software utilizado como parte de um sistema e so resultados de atributos estticos que podem ser obtidos por meio de medidas internas do software. Apresenta tambm um modelo de qualidade em uso de sistemas, composto de caractersticas e subcaractersticas que podem ser medidas quando um produto de software utilizado num contexto de uso real. ISO/IEC 25012 - Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Data quality model (publicada pela ISO) Esta norma define um modelo geral de qualidade de dados utilizados de forma estruturada num sistema computacional. O modelo define caractersticas de qualidade de dados que podem ser utilizados por pessoas ou sistemas. Diviso Medio da Qualidade

MPS.BR-Guia de Aquisio:2011

69/96

ISO/IEC 25020 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Measurement reference model and guide (publicada pela ISO) ABNT NBR ISO/IEC 25020 - Guia e Modelo de Referncia para Medio (publicada pela ABNT) Esta norma apresenta uma introduo aos elementos de medida de qualidade, medidas de qualidade interna, externa e de qualidade em uso e um modelo de referncia. Alm disso, fornece orientaes aos usurios para selecionar ou desenvolver e aplicar medidas de qualidade de produto de software. ISO/IEC TR 25021 - Systems and software engineering: Software product Quality Requirements and Evaluation (SQuaRE) - Quality measure elements (em reviso pela ISO) Este relatrio tcnico fornece um conjunto inicial de elementos de medidas de qualidade, para subsidiar os usurios das demais normas na escolha de medidas de qualidade de software, as quais so obtidas a partir da combinao de elementos de medidas de qualidade. ISO/IEC 25022 Systems and software engineering: Systems and software product Quality Requirements and Evaluation (SQuaRE) Measurement of quality in use Esta norma, cujo trabalho foi iniciado recentemente pela ISO/IEC, pretende definir medidas de qualidade em uso, segundo o modelo de qualidade da ISO/IEC 25010. ISO/IEC 25023 - Systems and software engineering: Systems and software product Quality Requirements and Evaluation (SQuaRE) Measurement of systems and software product quality Esta norma, cujo trabalho foi iniciado recentemente pela ISO/IEC, pretende definir medidas de qualidade de sistemas e de produto de software, segundo o modelo de qualidade da ISO/IEC 25010. ISO/IEC 25024 - Systems and software engineering: Systems and software product Quality Requirements and Evaluation (SQuaRE) Measurement of data quality Esta norma, cujo trabalho foi iniciado recentemente pela ISO/IEC, pretende definir medidas de qualidade de dados, segundo o modelo de qualidade da ISO/IEC 25012. Diviso Requisitos de Qualidade ISO/IEC 25030 - Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Quality requirements (publicada pela ISO) ABNT NBR ISO/IEC 25030 - Engenharia de software Requisitos e Avaliao da Qualidade de Produto de Software (SQuaRE) Requisitos de qualidade (publicada pela ABNT) Esta norma fornece os requisitos e recomendaes para a especificao de requisitos de qualidade de produto de software, podendo ser aplicada tanto por adquirentes quanto por fornecedores de produto de software. Diviso Avaliao da Qualidade

MPS.BR-Guia de Aquisio:2011

70/96

ISO/IEC 25040 Systems and software engineering Systems and software product Quality Requirements and Evaluation (SQuaRE) Evaluation reference model and guide (publicada pela ISO) Esta norma define requisitos gerais para avaliao da qualidade de produto de software. Descreve um processo de avaliao, estabelecendo os requisitos a serem seguidos na aplicao deste processo. O processo pode ser aplicado para a avaliao de produtos de software pr-desenvolvidos ou, ainda, para produtos de software sob encomenda. Esta nova norma, diferentemente da srie ISO/IEC 14598, define num nico documento as vises de avaliao para desenvolvedores, adquirentes ou avaliao utilizando-se terceira-parte. ISO/IEC 25041 Systems and software engineering Systems and software product Quality Requirements and Evaluation (SQuaRE) Evaluation guide for developers, acquirers and independent evaluators (em elaborao pela ISO) Esta norma fornece requisites e orientaes para avaliao de produto de software segundo a perspectiva de desenvolvedores, adquirentes e avaliadores independentes. ISO/IEC 25042 Systems and software engineering Systems and software product Quality Requirements and Evaluation (SQuaRE) Evaluation modules Esta norma, cujo trabalho ainda no foi iniciado pela ISO, pretende definir a estrutura e o contedo da documentao a ser utilizada para descrever um mdulo de avaliao. ISO/IEC 25045 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Evaluation module for recoverability (publicada pela ISO) Esta norma descreve um mdulo de avaliao que permite avaliar a capacidade de um sistema de tratar de perturbaes que lhe sejam induzidas, o modo como elas so detectadas e analisadas e como o sistema se ajusta e se recupera destes eventos. Extenso do SQuaRE ISO/IEC 25051 - Software Engineering Software product Quality Requirements and Evaluation (SQuaRE) Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing (publicada pela ISO) ABNT NBR ISO/IEC 25051 - Engenharia de software - Requisitos e avaliao da qualidade de produto de software (SQuaRE) Requisitos de qualidade de produto de software comercial de prateleira (COTS) e instrues para teste (publicada pela ABNT) Esta Norma estabelece requisitos de qualidade para produto de software comercial de prateleira (COTS) e requisitos para a documentao de testes de COTS, incluindo requisitos de teste, casos de teste e relatrio de teste. Fornece tambm instrues para a avaliao de conformidade de COTS, alm de incluir recomendaes para COTS crticos para negcios ou para segurana. ISO/IEC TR 25060 - Software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for Usability General Framework for Usability-related Information (em elaborao pela ISO)

MPS.BR-Guia de Aquisio:2011

71/96

Este relatrio tcnico define uma viso geral de um framework, utilizado para documentar a especificao da avaliao de usabilidade de sistemas interativos, chamado de Formatos Comuns da Indstria, descrevendo o seu contedo esperado, as definies e relacionamentos entre os elementos do framework. Alm disso define os usurios esperados do framework, bem como as situaes em que ele aplicvel. ISO/IEC 25062 - Software engineering: Software product Quality Requirements and Evaluation (SquaRe) - Common Industry Format (CIF) for Usability Test Reports (publicada pela ISO) ABNT NBR ISO/IEC 25062 - Engenharia de software Requisitos e avaliao da qualidade de produto de software (SQuaRE) Formato comum da indstria (FCI) para relatrios de teste de usabilidade Esta norma define como registrar as medidas obtidas em testes de usabilidade, onde so avaliadas as caractersticas de eficcia, eficincia e satisfao num contexto de uso especificado (estas caractersticas definem usabilidade conforme a norma ISO 9241-11).

MPS.BR-Guia de Aquisio:2011

72/96

Anexo I Processos de aquisio da ISO/IEC 12207 e IEEE STD 1062:1998 I.1 Processo da ISO/IEC 12207

Mantendo aderncia s definies de processo estabelecidas no Modelo de Referncia MR-MPS, o processo de aquisio est orientado pela norma ISO/IEC 12207:2008. Nesta seo ser descrito, de forma geral, o processo da ISO/IEC 12207 para aquisio de S&SC e seu relacionamento com a IEEE STD 1062:1998, norma que poder fornecer informaes complementares teis para organizaes que pretendam adquirir software. A ISO/IEC 12207 foi publicada, originalmente, em 1995 e teve uma nova verso publicada em 2008. uma Norma Internacional e descreve os processos que compem o ciclo de vida, sua interface com outros processos e as relaes em alto nvel que governam estas interaes. A norma cobre o ciclo de vida do software desde a sua concepo at o final de sua vida til. A norma usada como referncia em diversos pases, inclusive no Brasil, para permitir que as empresas atinjam um patamar competitivo compatvel com o existente nas organizaes internacionais. Ela tem por objetivo auxiliar os envolvidos na produo de software a definir seus papis e, assim, proporcionar s organizaes que a utilizam um melhor entendimento das atividades a serem executadas nas operaes que envolvem, de alguma forma, o software. A norma utiliza uma terminologia bem definida e composta de processos, atividades e tarefas para aquisio, fornecimento, desenvolvimento, operao e manuteno do software. A norma estabelece uma arquitetura de alto nvel para o ciclo de vida do software que abrange desde a concepo at a sua descontinuidade. Cada processo definido em termos de suas prprias atividades, e cada atividade adicionalmente definida em termos de suas tarefas A Tabela 1 apresenta os processos de contratao que tratam do assunto aquisio, so eles aquisio propriamente dita e fornecimento. O processo de aquisio o objetivo especfico deste documento, enquanto que o processo de fornecimento a viso complementar que orienta organizaes que utilizem a norma ISO/IEC 12207 para atendimento aos respectivos requisitos de aquisio.

Processos de contratao

Definem as atividades estabelecimento de um organizaes.

necessrias para o contrato entre duas

Aquisio

Define as atividades do adquirente (organizao que adquire um S&SC). Inicia-se com a definio da necessidade de adquirir um sistema, um produto ou um servio de software e continua com a preparao e a emisso de pedido de proposta, com a seleo do fornecedor, a monitorao do contrato at a aceitao do sistema, produto ou servio de software. Define as atividades do fornecedor (organizao que fornece S&SC ao adquirente). O processo pode ser

Fornecimento

MPS.BR-Guia de Aquisio:2011

73/96

iniciado tanto pela deciso de preparar uma proposta para atender solicitao de um adquirente, quanto pela assinatura e celebrao de um contrato com o adquirente para fornecer o sistema ou S&SC. O processo continua com a disseminao dos procedimentos e recursos necessrios para gerenciar e garantir o projeto, incluindo o desenvolvimento e a execuo dos planos de projeto at a entrega do sistema ou S&SC para o adquirente. Tabela 1 Descrio dos processos de contratao relacionados aquisio [ROCHA, 2001] A ISO/IEC 12207 considerada de grande importncia para os processos internacionais de aquisio de software. uma norma apropriada para os processos de aquisio porque reconhece as distintas funes existentes para os compradores e fornecedores. Esta norma tem a inteno de ser usada pelas partes quando existir entre elas um acordo ou contrato que define o desenvolvimento, manuteno ou operao de um sistema de software. O processo de aquisio, definido pela ISO/IEC 12207, tem como propsito obter um produto ou servio que satisfaa a necessidade expressa pelo cliente. O processo inicia com a identificao de uma necessidade do cliente e encerra com a aceitao do produto ou servio. Este processo constitudo pelas seguintes atividades: Preparao da aquisio tem como propsito estabelecer as necessidades e os objetivos da aquisio e comunic-los aos fornecedores em potencial. Seleo do fornecedor tem como propsito escolher a organizao que ser responsvel pelo atendimento aos requisitos do projeto. Monitorao do contrato tem como propsito acompanhar e avaliar o desempenho do fornecedor em relao aos requisitos acordados. Aceitao pelo cliente tem como propsito aprovar os produtos entregues pelo fornecedor quando todos os critrios de aceitao so satisfeitos. I.2 Processo da IEEE STD 1062:1998 Alm da norma ISO/IEC 12207, que a principal referncia para este documento, tambm devem ser considerados outros padres criados por associaes de profissionais, como o caso da norma IEEE STD 1062:1998 [IEEE 1062], que especfica para a aquisio de S&SC. Esta norma conhecida e utilizada internacionalmente, porm no Brasil no existem dados registrados de uso desse padro. H, nos Estados Unidos, cinco organizaes voltadas para o desenvolvimento da tecnologia de processos de desenvolvimento de software. Duas delas so especficas para a aquisio de produtos e servios de software: Outsourcing Center [OUTC, 2002] e COTS Group [COTS, 2002]. Na Europa existe tambm esta preocupao e, como exemplo, h na Unio Europeia o EUROMethod , o European Procurement Handbook for Open Systems -

MPS.BR-Guia de Aquisio:2011

74/96

EPHOS [EFHOS]. H grupos especficos para aquisio, dentre eles destaca-se: The Procurement Forums Special Interest Groups [PROCURE]. A norma IEEE STD 1062:1998 - IEEE Recommended Practice for Software Acquisition, alm de ser aderente norma ISO/IEC 12207 Emenda 1, considerada como um framework com a mesma relevncia da prpria ISO/IEC 12207, do SWCMM, SA-CMM, FAAiCMM, ISO 9000, ISO/IEC 15504, e Euromethod e pode ser utilizada para a aquisio de qualquer produto de software, para qualquer tipo de plataforma computacional, independente do tamanho, complexidade e criticidade do software, embora seja mais adequada para o uso quando da aquisio de software de prateleira modificvel (modified off the shelf software (MOTS)) e software por encomenda (partially to fully outsourced (FD)). A classificao adotada pela IEEE STD 1062:1998 para os produtos de software definida conforme o grau de liberdade que tem o usurio em definir e especificar suas funcionalidades. Segundo a norma, h trs tipos de produtos de software: Commercial-off-the-shelf-software (COTS), Modified-off-the-shelf-software (MOTS) e Fully Developed Software (FD). O software do tipo COTS est comercialmente disponvel. Ele normalmente bem definindo e documentado e o seu uso em escala, por um grande nmero de usurios demonstra seu bom desempenho em uso. O fornecedor no est disponvel para modificar o software s necessidades de um cliente especfico e nem para controlar a manuteno do software. O custo para adquirir o software de baixo para mdio e a entrega do produto imediata. No software do tipo MOTS, software de prateleira modificvel, o cliente no tem controle sob a qualidade de suas caractersticas, parecido com o software do tipo COTS, com a diferena de que o fornecedor est disponvel para efetuar modificaes das funcionalidades do produto de software, segundo os requisitos do cliente. O seu bom desempenho no uso pode ser demonstrado em aplicaes semelhantes utilizadas por outros clientes. O cliente tem um controle relativo da manuteno do produto e de suas caractersticas de qualidade na parte personalizada. O tempo de entrega varia de mdio para longo e o custo para o cliente de mdio para alto. O terceiro tipo FD, software sob encomenda (fully developed software) nico, tem um volume baixo de aplicao e desenvolvido para atender completamente os requisitos de um cliente especfico. Como o produto no tem precedente o seu desempenho no pode ser avaliado a priori, mas o cliente possui total controle sobre suas caractersticas de qualidade e manuteno. O custo de desenvolvimento para o cliente alto e o tempo de entrega longo. As caractersticas destas classes de produto esto resumidas na Tabela 2. Caractersticas Escopo Adequao ao uso Manuteno COTS Fixo Demonstrado Sem controle MOTS Parcialmente personalizado Demonstrado em aplicaes similares Controle parcial FD* Totalmente personalizado Sem precedentes Controle total

MPS.BR-Guia de Aquisio:2011

75/96

Prazo de Entrega Custo da aquisio

Imediato Baixo - Mdio

Pequeno - Grande Mdio - Alto Parcialmente controlada

Grande Alto Controlada em sua maior parte

Qualidade [ABNT NBR ISO/IEC No controlada 9126-1]

(*) Parcialmente ou completamente terceirizado Tabela 2 Caractersticas das classes de produto segundo a IEEE STD 1062:1998 Segundo a norma, o ciclo de vida da aquisio de software representa o perodo de tempo que comea com a deciso de adquirir um produto de software e termina quando o produto tem seu uso descontinuado. Este ciclo de vida representa um framework para a aquisio. Os resultados, produo ou sada de uma fase so usados como entrada para a fase seguinte. A Tabela 3 apresenta a ilustrao dessas fases.
Fase Incio de Fase Fim de fase Passo no Processo de Aquisio de Software 1. Planejamento da estratgia organizacional, 2. Implementao do processo organizacional 3. Definio dos requisitos do software 4. Identificao dos potenciais fornecedores 5. Preparao dos requisitos do contrato 6. Avaliao das propostas e seleo do fornecedor 7. Gerncia do desempenho do fornecedor 8. Aceitao do software 9. Utilizao do software

Planejamento

Desenvolvimento da ideia

Chamada para proposta atualizada

Contratao

Atualizao da chamada para proposta

Contrato assinado

Implementao do software Aceitao do software Acompanhamento

Assinatura do contrato Recebimento do software Aceitao do software

Recepo do software Aceite do software Aposentadoria do software

Tabela 3 Fases do processo de aquisio de software segundo a IEEE STD 1062:1998 A norma define nove passos que devem ser seguidos para assegurar que os produtos com alto potencial de qualidade sejam devidamente pontuados, contemplados e considerados no processo de aquisio. O resultado esperado deve ser um software de alta qualidade e documentao adequada. Atributos como prazo de entrega e custos so deixados a critrio do usurio da norma. A Tabela 3 apresenta as fases, marcos e indica quais aes devem ser executadas e cumpridas

MPS.BR-Guia de Aquisio:2011

76/96

em cada uma das fases. Os passos tm como foco a aquisio de software com um conjunto bsico de funcionalidades com possibilidade de serem desenvolvidas, ou componentes de software acabados. Esses passos so menos adequados para software com necessidade de implementao rpida. Os passos so: 1- Planejamento da estratgia organizacional: rev os objetivos da aquisio e desenvolve uma estratgia para a aquisio do software. 2- Implementao do processo organizacional: estabelece um processo de aquisio de software que atende as necessidades da organizao em obter um produto de qualidade. 3- Definio dos requisitos de software: define o software que deve ser adquirido e prepara os planos com os requisitos de qualidade e de manuteno para a aceitao do software. 4- Identificao dos potenciais fornecedores: seleciona os candidatos potenciais que devero apresentar a documentao de seu software, efetuar a demonstrao dos produtos, e apresentar as propostas formais de fornecimento. A no observao ou desempenho medocre em qualquer uma destas aes considerado como base ou argumento suficiente para a rejeio do potencial fornecedor. 5- Preparao dos requisitos do contrato: descreve a qualidade do trabalho a ser feito em termos de desempenho e critrios de aceitao e prepara as condies contratuais que estabelece a previso de pagamento de acordo com a entrega do software. 6- Avaliao das propostas e seleo do fornecedor: as propostas dos fornecedores so avaliadas, feita a escolha do fornecedor qualificado e o contrato negociado. 7- Gerncia do desempenho do fornecedor: o progresso do trabalho do fornecedor monitorado para garantir o cumprimento dos marcos e para aprovao das partes executadas do trabalho. O comprador ou adquirente deve, nesta fase, providenciar todos os insumos ao fornecedor, quando solicitado. 8- Aceitao do software: devem ser executados testes, conforme estabelece o processo, para garantir que todas as no conformidades sejam corrigidas e que todos os critrios de aceitao sejam satisfeitos. 9- Utilizao do software: so realizados acompanhamento e anlise do contrato de aquisio para avaliar as prticas do contrato, registrar as lies aprendidas e avaliar a satisfao do usurio com o produto. Os dados de desempenho do fornecedor devem ser armazenados. Segundo a norma, o sucesso na aquisio de um software ou servio correlato de alta qualidade pode ser alcanado se as seguintes aes forem executadas: a) identificao das caractersticas de qualidade necessrias para atingir os objetivos do comprador ou adquirente; b) incluso de consideraes de qualidade nas atividades de planejamento, avaliao e aceitao do produto; c) implementao de uma estratgia organizacional para a aquisio de software;

MPS.BR-Guia de Aquisio:2011

77/96

d) implementao de um processo de aquisio de software usando os nove passos sugeridos pela norma no texto anterior; e e) colocao do processo em prtica. A Figura 4 relaciona os passos previstos na norma IEEE STD 1062:1998 com as atividades estabelecidas na ISO/IEC 12207:2008, indicando a possibilidade de complementao do processo estabelecido neste guia, que compatvel com esta norma da ISO/IEC.

ISO/IEC 12207

IEEE STD 1062 Preparar estratgia organizacional

Preparao da aquisio

Implem. processo organizacional Determinar requisitos software Identificar potenciais fornecedores

Seleo de fornecedor

Preparar requisitos do contrato Avaliar propostas/selec. fornecedor

Monitorao do contrato Aceitao pelo cliente

Gerenciar desempenho fornecedor Aceitar o software Utilizar o software

Figura 4 - Relacionamento da ISO/IEC 12207:2008 e a IEEE STD 1062:1998

MPS.BR-Guia de Aquisio:2011

78/96

Anexo J Habilitao de consultores de aquisio MPS J.1 Habilitao de consultores de aquisio. Assim como nas demais reas do MPS.BR, para o processo de aquisio tambm h uma sistemtica para formao e reconhecimento de profissionais. Os profissionais, para serem habilitados como Consultores de Aquisio MPS, devem apresentar qualificao profissional e acadmica, alm de cumprirem os requisitos de treinamento, avaliao e elaborao de um Plano de Aquisio de Software, conforme detalhados no site www.softex.br/mpsbr e resumidos a seguir. I. Participao no curso do Processo de Aquisio MPS (C4); II. Aprovao na prova sobre o Processo de Aquisio MPS (P4): esta prova consiste na soluo de um caso que aborda alguns aspectos envolvidos em um projeto de aquisio. Para ser aprovado, o candidato necessita atingir, pelo menos, 70% do escore mximo; III. Demonstrao, comprovada por meio de anlise curricular, que o candidato desenvolve ou desenvolveu atividades de execuo ou de gesto em projetos de aquisio de software e servios correlatos ou em definio e/ou implantao de processos de aquisio de software e servios correlatos. A experincia demonstrada dever ser suficiente para assegurar a capacidade do candidato para atuar como Consultor de Aquisio (CA) com base no Guia de Aquisio do MPS.BR. O resultado do julgamento indicar se o candidato foi aprovado e IV. Habilitao: caso o candidato cumpra os requisitos estabelecidos, seu nome ser publicado na seo Profissionais Habilitados em Acesso Rpido no site www.softex.br/mpsbr como Consultor de Aquisio MPS. A habilitao pode ser cancelada, a qualquer tempo, caso o Consultor de Aquisio MPS, por alguma ao ou omisso, coloque em risco a credibilidade do MPS.BR.

MPS.BR-Guia de Aquisio:2011

79/96

Anexo K Iniciativas de utilizao de processos de aquisio na rea pblica K.1 Personalizao de processo de aquisio A adoo de um processo de aquisio por qualquer organizao, nos moldes do que foi definido neste Guia de Aquisio, exige uma personalizao do processo geral s caractersticas peculiares da organizao e do contexto onde ela est inserida. Neste sentido, a personalizao do processo de aquisio deve levar em conta aspectos como os relacionados a seguir: Contexto da organizao: caractersticas da organizao que podem afetar os projetos de aquisio de S&SC. Estes aspectos podem definir requisitos e restries a serem considerados nos projetos de aquisio. Entre eles, podem ser includos: o o o o o o Demais processos da organizao relacionados ao processo de aquisio; Ambiente de hardware e software adotado; Habilidades e qualificaes do pessoal envolvido em aquisies de S&SC; Poltica de formao das pessoas que atuam em aquisies de S&SC; Polticas de contratao de produtos e servios da organizao; Definies estabelecidas no plano estratgico da organizao que podem influenciar as aquisies de S&SC. que sejam diretamente

o Diretrizes, projetos e aes estratgicas definidas no Plano Diretor de Tecnologia da Informao (TI). o Processos de governana de TI que subsidiam aquisio como planejamento estratgico, gesto de investimentos, gesto de portflio de projetos, gesto de riscos, gesto da contratao de servios de TI e o de medio. Contexto regulatrio: leis e regulamentos externos e internos que regem o funcionamento da organizao, principalmente no que diz respeito aquisio de S&SC. Estas informaes devem estar organizadas em um repositrio que facilite o acesso, entendimento e aplicao das regras aplicveis a cada projeto de aquisio de S&SC; Contexto do mercado: aspectos referentes ao mercado com o qual a organizao se relaciona e que influenciam os seus projetos de aquisio. Entre outros, destacam-se os seguintes aspectos: o o o Produtos existentes com potencial de atendimento s necessidades da organizao; Potenciais fornecedores de S&SC e seu histrico de prestao de servios organizao; Referncias de uso de produtos e servios de interesse da organizao por outras organizaes;

MPS.BR-Guia de Aquisio:2011

80/96

Referncias tcnicas e comerciais aplicveis aos projetos de aquisio de S&SC da organizao.

Processos de governana e gesto da organizao: processos adotados na organizao para gesto de projetos, contemplando gesto de requisitos, comunicaes, custos, mudanas, problemas, prazos e qualidade e que podem ser aplicveis em projetos de aquisio de S&SC; Instrumentos de apoio: mtodos, tcnicas e ferramentas que a organizao utiliza nos seus projetos de aquisio de S&SC. K.2 Personalizao de processo de aquisio para organizaes pblicas A adoo de um processo de aquisio de S&SC personalizado para a administrao pblica de fundamental importncia, seja pelos altos investimentos envolvidos ou, principalmente, pelos benefcios que podem ser obtidos em favor da sociedade brasileira a partir de um projeto de aquisio que obtenha sucesso. De acordo com a norma ABNT NBR ISO/IEC 38500:2009 [ABNT, 2009c], p. 6, atualmente a nica norma referencial sobre governana corporativa de TI no Brasil, o princpio da aquisio um entre os seis que devem nortear a boa governana de TI: As aquisies de TI so feitas por razes vlidas, com base em anlise apropriada e contnua, com tomada de deciso clara e transparente. Existe um equilbrio apropriado entre benefcios, oportunidades, custos e riscos, de curto e longo prazo. Na Administrao Pblica Federal (APF) a aquisio tratada como contratao de servios de TI, com base principalmente na Lei 8.666/1993. O Tribunal de Contas da Unio (TCU) tem identificado frequentes irregularidades e impropriedades em contrataes de servios de TI. Diante desse contexto, em 2006 o TCU criou a Secretaria de Fiscalizao de Tecnologia da Informao, instituiu a pesquisa de governana de TI em rgos pblicos e recomendou a elaborao de um modelo de licitao e contratao de servios de TI com processos mais maduros e a sua implantao nos rgos e entidades sob a coordenao da Secretaria de Logstica e Tecnologia da Informao do Ministrio do Planejamento, Oramento e Gesto (SLTI/MP) [TCU, 2006, item 67 do Voto do Relator e item 9.4 do Acrdo]. Em seguida observou-se um movimento positivo da SLTI/MP, que o rgo central do Sistema de Administrao dos Recursos de Informao e Informtica (SISP), na implementao de diretrizes para contratao de servios de TI pela APF direta, autrquica e fundacional, com resultados importantes, conforme identificados por Cruz, Andrade e Figueiredo [CRUZ, ANDRADE, FIGUEIREDO, 2011] apresentados a seguir: a) Em maio de 2008, a elaborao e publicao da Instruo Normativa SLTI/MP04/2008 (IN-04/2008) [MPOG, 2008b]. Esta IN define as diretrizes e fases do processo de contratao de servio de TI e foi concebida tomando por base, entre outras fontes, a legislao brasileira, os resultados preliminares da pesquisa de [Cruz, 2008] que resultaram no Quadro Referencial Normativo para contratao de servios de TI, apresentados em 19/12/2007, e nas experincias dos gestores envolvidos no grupo de trabalho organizado pela SLTI para apoiar a construo desta IN;

MPS.BR-Guia de Aquisio:2011

81/96

b) Em dezembro de 2008, a publicao de um instrumento balizador das diretrizes estratgicas e metas de aprimoramento institucional do SISP, denominado Estratgia Geral de Tecnologia da Informao (EGTI) [MPOG, 2008a]. O objetivo da EGTI foi estabelecer as bases para o cumprimento da IN-04/2008, para que os rgos do SISP elaborassem seus Planos Diretores de Tecnologia da Informao (PDTI), buscando o aprimoramento institucional e a maturidade da governana de TI. A palavra sntese foi transio; c) Em 2009, o governo criou a Gratificao Temporria do Sistema de Administrao dos Recursos de Informao e Informtica (GSISP), atraindo funcionrios pblicos para atuao na rea de governana de TI, e criou o cargo de Analista em TI (ATI) com atribuies voltadas s atividades de planejamento, superviso e controle dos recursos, com o intuito de reforar as unidades de TI; d) A SLTI tambm implantou um programa de desenvolvimento de gestores de TI, por meio da Escola Nacional de Administrao Pblica (ENAP), com quatro mdulos: i) elaborao do plano diretor de TI; ii) planejamento da contratao; iii) seleo de fornecedores; e iv) gesto de contratos; e) Ainda em 2009, a EGTI 2008 foi revisada e considerando o aumento de profissionais de TI, publicando-se a EGTI 2010 [MPOG, 2010a] cuja palavra sntese foi agregao de valor; f) Em 2010, a IN 04/2008 foi revisada, melhorada e publicada como IN 04/2010 [MPOG, 2010a]. Essa reviso da IN 04 ocorreu devido s necessidades de detalhamento das etapas e fases; de clarificar as atribuies dos atores; facilitar o envolvimento das reas de requisitante da soluo e administrativa no planejamento da contratao e na gesto de contratos; clarear as orientaes para incluso e gesto das sanes administrativas; g) Em seguida, foi publicada a EGTI 2011-2012 [MPOG, 2011], que tem como misso promover a gesto dos recursos de TI nos rgos integrantes do sistema visando apoiar o desenvolvimento social do Pas. O resultado dessa evoluo jurdica uma clara preocupao com a melhoria do planejamento de TI, planejamento da contratao, seleo do fornecedor e gesto de contratos em todos os processos da tecnologia da informao, incluindo os processos de S&SC. Portanto, requerido normativamente que as organizaes pblicas definam e institucionalizem seus processos de contratao de servios de TI. A Instruo Normativa SLTI/MP 4/2010 ([MPOG, 2010a], mais conhecida pela sigla IN 04 define as diretrizes do processo de Contratao de Solues de Tecnologia da Informao pelos rgos integrantes do Sistema de Administrao dos Recursos de Informao e Informtica do Poder Executivo Federal (SISP), estabelecido pelo Decreto 1.048/1994 [BRASIL, 1994]. As principais alteraes da IN 04 foram: i) criao da equipe de planejamento da contratao (integrante demandante, integrante tcnico e integrante administrativo); ii) definio dos papis de integrantes da equipe de planejamento da contratao, gestor, co-gestor e fiscais contratuais; iii) definio dos responsveis em cada etapa das fases no processo de contratao (planejamento, seleo de fornecedores e gesto do contrato); iv) criao do

MPS.BR-Guia de Aquisio:2011

82/96

documento oficializao da demanda; v) mais detalhes na fase de seleo do fornecedor e na definio das sanes administrativas. A IN-04 compe-se de trs captulos, conforme apresenta a Figura 1 abaixo:

EGTI
Captulo I Disposies Gerais

PDTI
Seo I Planejamento da contratao

Captulo II Processo de contratao

Seo II Seleo do fornecedor

Captulo III Disposies finais

Seo III Gerenciamento do contrato

Figura 1 - Estrutura da IN-04 - Fonte: [CRUZ, ANDRADE, FIGUEIREDO, 2011] O captulo I apresenta as disposies gerais sobre as diretrizes relacionadas ao Planejamento de TI, que abrange a Estratgia Geral de Tecnologia da Informao (EGTI) e o Plano Diretor de Tecnologia da Informao (PDTI): a) A (EGTI), elaborada pelo SISP, revisada anualmente e contm orientaes gerais para aperfeioar a gesto de processos de TI nos rgos do SISP, e uma das metas adotar um processo de contrataes de solues de TI, conforme as publicaes da IN-04/2010 e do Manual de Contrataes de Solues de TI. b) O PDTI um documento obrigatrio para cada rgo ou entidade integrante do SISP. Neste documento so apresentados a avaliao e o diagnstico dos recursos de TI, as necessidades de informao identificadas pelo rgo, alm do planejamento de investimentos, recursos humanos e sua capacitao, aquisio de equipamentos e contrataes de servios de TI. O Captulo II apresenta o processo de contratao de servios de TI, constitudo das fases de planejamento da contratao (seo I), de seleo do fornecedor (seo II) e de gerenciamento do contrato (seo III). Todas as contrataes de solues de tecnologia da informao devero ser precedidas de planejamento da contratao, independente do tipo de contratao, quer seja: licitao convencional (prego, concorrncia, tomada de preos, convite ou concurso), inexigibilidade e dispensa de licitao, sistema de registro de preos e contrataes com recursos de convnios internacionais. Na fase de PLANEJAMENTO DA CONTRATAO, observam-se os cuidados com a definio das responsabilidades dos envolvidos, justificativas e resultados esperados e fonte de recursos. O resultado dessa fase caracterizado pela produo do termo de referncia ou do projeto bsico, mas o seu incio marcado pelo recebimento do Documento de Oficializao da Demanda, pela rea de Tecnologia da Informao,

MPS.BR-Guia de Aquisio:2011

83/96

oriundo da rea Requisitante da Soluo, que conter no mnimo as seguintes sees: a) Necessidade da contratao, considerando os objetivos estratgicos e as necessidades corporativas da instituio, bem como o seu alinhamento ao PDTI; b) Explicitao da motivao e demonstrativo de resultados a serem alcanados; c) Indicao da fonte dos recursos para a contratao; e d) Indicao do Integrante Requisitante para composio da Equipe de Planejamento da Contratao. Essa fase constitui-se das seguintes etapas: a) Anlise de Viabilidade da Contratao abrange a definio e especificao dos requisitos; identificao, avaliao e seleo de solues; justificativa da soluo selecionada; avaliao da necessidade de adequao da soluo; consolidao das informaes; e avaliao da anlise de viabilidade. Nessa etapa verificada tambm a possibilidade de parcelamento da Soluo de Tecnologia da Informao (Art. 17, 2) em atendimento aos arts. 15 e 23, 1, da Lei 8.666/1993 e ao Acrdo 786/2006-TCU-Plenrio; b) Elaborao do Plano de Sustentao - abrange a segurana da informao; recursos materiais e humanos; transio contratual; continuidade do fornecimento da soluo de Tecnologia; da Informao em eventual interrupo contratual; e estratgia de independncia; consolida informaes e avalia o plano de sustentao. assinado pelo Requisitante da Soluo e rea de TI; c) Elaborao da Estratgia da Contratao abrange a indicao da soluo de TI, termos contratuais, responsabilidades de contratao, elaborao de modelos de documentos e estimativa de impactos; define critrios de julgamento; consolida informaes e avalia a estratgia da contratao. Alm destas atividades, analisa a necessidade de licitaes e contrataes separadas para os itens que, devido sua natureza, possam ser objeto de recursos e que possam paralisar a contratao de itens da Soluo de Tecnologia da Informao.
d)

Anlise de Riscos abrange a identificao dos principais riscos que possam comprometer o sucesso do processo de contratao e de modo que a soluo contratada no atenda s necessidades do rgo; nveis de probabilidade e severidade de cada risco; aes para amenizar ou eliminar as chances de ocorrncia; aes de contingncia; responsveis pelas aes de preveno ou procedimentos de contingncia. Os responsveis pela elaborao so os integrantes tcnicos e demandantes, com o apoio da rea de TI.

e) Elaborao do Termo de Referncia ou Projeto Bsico documento com o planejamento completo da contratao e seus respectivos anexos. A fase SELEO DO FORNECEDOR refora o uso rotineiro do Prego (e excepcional de outros tipos e modalidades de mecanismo de seleo do fornecedor) para as contrataes de Soluo de Tecnologia da Informao. Essa fase inicia com

MPS.BR-Guia de Aquisio:2011

84/96

o encaminhamento do termo de referncia (ou projeto bsico) pela rea de TI rea de licitaes, cabendo ltima a responsabilidade pela fase e rea de TI apenas: a) analisar as sugestes feitas pelas reas de Licitaes e Jurdica para o Termo de Referncia ou Projeto Bsico e demais documentos; b) apoiar tecnicamente o pregoeiro ou a Comisso de Licitao na resposta aos questionamentos ou s impugnaes dos licitantes; e c) apoiar tecnicamente o pregoeiro ou a Comisso de Licitao na anlise e julgamento das propostas e dos recursos apresentados pelos licitantes. A fase Seleo do Fornecedor encerrada com a assinatura do contrato e com a nomeao de pessoas para exercerem os seguintes papis: a) Gestor do Contrato; b) Fiscal Tcnico do Contrato; c) Fiscal Requisitante do Contrato; e d) Fiscal Administrativo do Contrato. A fase de GERENCIAMENTO DO CONTRATO foca no acompanhamento e na garantia adequada da prestao dos servios e do fornecimento dos bens que compem a Soluo de Tecnologia da Informao durante todo o perodo de execuo do contrato, com as etapas: a) Incio do contrato; b) Encaminhamento formal de ordens de servio ou de fornecimento de bens pelo Gestor do Contrato ao preposto da contratada; c) Monitoramento da execuo; d) Transio contratual, quando aplicvel, e encerramento do contrato, que dever observar o Plano de Sustentao; e) Ajustes contratuais, por meio do encaminhamento rea Administrativa de documentao explicitando o interesse de aditamento contratual, baseado na documentao do histrico de gerenciamento do contrato, na manuteno da necessidade, economicidade e oportunidade da contratao. Enfatiza-se que, nos casos de contratao de desenvolvimento de software, os produtos devero ser catalogados pelo contratante e, sempre que aplicvel, disponibilizados no Portal do Software Pblico. Juntamente com a publicao da IN-04, foi publicado tambm o Manual de Contratao de Solues de Tecnologia da Informao V. 2.0 [MPOG, 2010c], que descreve os processos, atividades e artefatos envolvidos na contratao, com o objetivo de apoiar os profissionais na realizao do processo de contratao de Solues de TI. Outra iniciativa importante do Governo foi a chamada em 2010 para publicao de um livro sobre aquisies em TI pelo Ministrio da Cincia, Tecnologia e Inovao/Secretaria de Poltica de Informtica, por meio da Srie de Livros do Programa Brasileiro de Qualidade e Produtividade em Software (PBQP). O Livro Processo de Contratao de Servios de Tecnologia da Informao para

MPS.BR-Guia de Aquisio:2011

85/96

Organizaes Pblicas [CRUZ, ANDRADE, FIGUEIREDO, 2011] foi o vencedor desse concurso. Esse livro apresenta um processo de contratao de servios de TI para rgos pblicos descrito com base na IN-04, no processo de aquisio do MPS.BR, nos modelos Cobit, objetivos de controle focados em contratao de servios: AI5 (Adquirir recursos de TI) e DS2 (Gerenciar servios terceirizados), no eSCM-CL (eSourcing Capability Model for Clients) e no QRN (Quadro Referencial Normativo). Portanto, processo descrito no livro pode ser considerado um exemplo de um processo personalizado.

MPS.BR-Guia de Aquisio:2011

86/96

Referncias bibliogrficas [ABNT, 2001a] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 14598-1:2001 - Tecnologia de informao - Avaliao de produto de software Parte 1: Viso geral. Rio de Janeiro: ABNT, 2001. [ABNT, 2001b] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 14598-5:2001 - Tecnologia de informao - Avaliao de produto de software Parte 5: Processo para avaliadores. Rio de Janeiro: ABNT, 2001. [ABNT, 2003a] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 9126-1:2003 - Engenharia de software - Qualidade de produto - Parte 1: Modelo de qualidade. Rio de Janeiro: ABNT, 2003. [ABNT, 2003b] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 14598-2:2003 - Engenharia de software - Avaliao de produto de software Parte 2: Planejamento e gesto. Rio de Janeiro: ABNT, 2003. [ABNT, 2003c] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 14598-3:2003 - Engenharia de software - Avaliao de produto de software Parte 3: Processo para desenvolvedores. Rio de Janeiro: ABNT, 2003. [ABNT, 2003d] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 14598-4:2003 - Engenharia de software - Avaliao de produto de software Parte 4: Processo para adquirentes. Rio de Janeiro: ABNT, 2003. [ABNT, 2004] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 14598-6:2004 - Engenharia de software - Avaliao de produto de software Parte 6: Documentao de mdulos de avaliao. Rio de Janeiro: ABNT, 2004. [ABNT, 2008a] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 25000:2008 - Engenharia de software - Requisitos e avaliao da qualidade de produtos de software (SQuaRE) - Guia do SQuaRE. Rio de Janeiro: ABNT, 2008. [ABNT, 2008b] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 25030:2008 - Engenharia de software - Requisitos e avaliao da qualidade de produto de software (SQuaRE) - Requisitos de qualidade. Rio de Janeiro: ABNT, 2008. [ABNT, 2008c] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 25051:2008 - Engenharia de software - Requisitos e avaliao da qualidade de produto de software (SQuaRE) - Requisitos de qualidade de produto de software comercial de prateleira (COTS) e instrues para teste. Rio de Janeiro: ABNT, 2008. [ABNT, 2009a] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 25001:2009 - Engenharia de software - Requisitos e avaliao da qualidade de produtos de software (SQuaRE) Planejamento e gesto. Rio de Janeiro: ABNT, 2009. [ABNT, 2009b] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 25020:2009 - Engenharia de software - Requisitos e avaliao da

MPS.BR-Guia de Aquisio:2011

87/96

qualidade de produtos de software (SQuaRE) Guia e modelo de referncia para medio. Rio de Janeiro: ABNT, 2009. [ABNT, 2009c] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. ABNT NBR ISO/IEC 38500:2009 - Governana corporativa de tecnologia da informao. Rio de Janeiro: ABNT, 2009. [ALVES, 2004] - ALVES, ngela M; GUERRA, Ana. Aquisio de Produtos e Servios de Software. Rio de Janeiro: Elsevier, 2004. 213p. [BRASIL, 1994] BRASIL. Decreto n 1.048, de 21 de janeiro de 1994. Dispe sobre o Sistema de Administrao dos Recursos de Informao e Informtica, da Administrao Pblica Federal, e d outras providncias. Braslia, 1994. Disponvel em: <http://www.planalto.gov.br/ccivil_03/decreto/19901994/D1048.htm>. Acesso em: 26 fev. 2010. [COLOMBO, 2004] - COLOMBO, Regina Maria Thienne. Processo de Avaliao da Qualidade de Pacotes de Software. Campinas, SP, 2004. 169pp. Orientadora Ana Cervigni Guerra. Trabalho Final de Mestrado Profissional. Universidade Estadual de Campinas, Faculdade de Engenharia Mecnica. [CMMI, 2002] - SEI. SOFTWARE ENGINEERING INSTITUTE. Capability Maturity Model Integration, Version 1.1. CMMI for Software Enginneering. Software Engineering Institute, August, 2002. [COTS, 2002] - COTS group. Disponvel em <www.cots.state.va.us>. ltimo acesso em 12 de abril 2002. [CRUZ, 2008] - CRUZ, Cludio Silva da. Governana de TI e conformidade legal no setor pblico: um quadro referencial normativo para a contratao de servios de TI. Dissertao (Mestrado em Gesto do Conhecimento e da Tecnologia da Informao). Universidade Catlica de Braslia, Braslia, 2008. Disponvel em: <http://www.bdtd.ucb.br/tede/tde_arquivos/3/TDE-2008-1125T123713Z-687/Publico/Texto Completo Cruz - 2008.pdf>. Acesso em: 26 fev. 2011. [CRUZ, ANDRADE, FIGUEIREDO, 2011] - CRUZ, Cludio Silva da; ANDRADE, Edmia Leonor Pereira de; FIGUEIREDO, Rejane Maria da Costa. PCSSCEG Processo de contratao de servios de tecnologia da informao para organizaes pblicas. Braslia: MCT/SEPIN, 2011. 109 p. il. Srie Livros PBQP. Disponvel em: http://mct.gov.br/index.php/content/view/331689.html [DSouza, 1998] DSouza, D.F. e Wills, A. C., 1998, Object, Components, and Frameworks with UML: The catalysis Approach, Addison-Weskey. [EPHOS] - EPHOS - European Procurement Handbook for Open Systems Disponvel em http://www.csi.map.es/csi/historico/pg5e20.htm . Ultimo acesso em 31.01.05. [EURO] - Comisso Europeia, DG III, PPG, Julho, 1996. EURO-Euromtodo v1.0. Disponvel em <http://projekte.fast.de/Euromethod>. ltimo acesso em 19 de maio de 2002. [IEEE, 1998] - IEEE COMPUTER SOCIETY. IEEE - Software Engineering Standards Colletion. IEEE STD 1062 - IEEE Recommended Practice for Software Acquisition. New York, NY. 1998a. 43p.

MPS.BR-Guia de Aquisio:2011

88/96

[ISO/IEC, 2002a] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-2:2003 - Software engineering - Product quality - Part 2: External metrics. Geneve: ISO, 2002. [ISO/IEC, 2002b] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-3:2003 - Software engineering - Product quality - Part 3: Internal metrics. Geneve: ISO, 2002. [ISO/IEC, 2002c] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-4:2002 - Software engineering - Product quality - Part 4: Quality in Use. Geneve: ISO, 2002. [ISO/IEC, 2006] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25062:2006 - Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for Usability Test Reports. Geneve: ISO, 2006. [ISO/IEC, 2007] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25001:2007 - Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Planning and management. Geneve: ISO, 2007. [ISO/IEC, 2008a] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 12207:2008 Systems and software engineering Software life cycle processes. Geneve: ISO, 2008. [ISO/IEC, 2008b] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25020:2008 - Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Measurement reference model and guide. Geneve: ISO, 2008. [MPOG, 2008a] - Ministrio do Planejamento, Oramento e Gesto. Secretaria de Logstica e Tecnologia da Informao. Estratgia Geral de TI 2008. Verso 1.0. Braslia, 2008. Disponvel em: <http://www.governoeletronico.gov.br/biblioteca/arquivos/portaria-no-11-de-30-dedezembro-de-2008>. Acesso em: 19 jun. 2006. [MPOG, 2008b] - Ministrio do Planejamento, Oramento e Gesto. Secretaria de Logstica e Tecnologia da Informao. Instruo Normativa SLTI n 4, de 19 de maio de 2008. Dispe sobre o processo de contratao de servios de Tecnologia da Informao pela Administrao Pblica Federal direta, autrquica e fundacional. Braslia, 2008. Disponvel em: <http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-042>. Acesso em: 26 fev. 2011.

MPS.BR-Guia de Aquisio:2011

89/96

[MPOG, 2010a] - Ministrio do Planejamento, Oramento e Gesto. Secretaria de Logstica e Tecnologia da Informao. Estratgia Geral de Tecnologia da Informao 2010. Braslia, SLTI/MP, 2010. [MPOG, 2010b] - Ministrio do Planejamento, Oramento e Gesto. Secretaria de Logstica e Tecnologia da Informao. Instruo normativa n 4, de 12 de novembro de 2010. Dispe sobre o processo de contratao de Solues de Tecnologia da Informao pelos rgos integrantes do Sistema de Administrao dos Recursos de Informao e Informtica (Sisp) do Poder Executivo Federal. Braslia, 2010. Disponvel em: <http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-04de-12-de-novembro-de-2010>. Acesso em: 26 fev. 2011. [MPOG, 2010c] - Ministrio do Planejamento, Oramento e Gesto. Secretaria de Logstica e Tecnologia da Informao. Manual de contratao de solues de tecnologia da informao. Verso 2.0. Braslia, 2010. Disponvel em: <http://www.governoeletronico.gov.br/biblioteca/arquivos/manual-de-contratacao-desolucoes-de-tecnologia-da-informacao>. Acesso em: 26 fev. 2011. [MPOG, 2011] - Ministrio do Planejamento, Oramento e Gesto. Secretaria de Logstica e Tecnologia da Informao. Estratgia Geral de Tecnologia da Informao EGTI 2011-2012. Braslia, 2011. Disponvel em: <http://www.governoeletronico.gov.br/biblioteca/arquivos/estrategia-geral-detecnologia-da-informacao-egti-2011-2012>. Acesso em: 26 fev. 2011. [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 Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS:2011, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011d] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS:2011, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011e] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 3: Fundamentao para Implementao do Nvel E do MR-MPS:2011, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011f] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS:2011, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011g] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte

MPS.BR-Guia de Aquisio:2011

90/96

5: Fundamentao para Implementao do Nvel C do MR-MPS:2011, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011h] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS:2011, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011i] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS:2011, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011j] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 8: Implementao do MR-MPS:2011 em organizaes que adquirem software, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011k] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 9: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de Software, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011l] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 10: Implementao do MR-MPS:2011 em organizaes do tipo Fbrica de Teste, junho 2011. Disponvel em: www.softex.br. [SOFTEX, 2011m] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS:2011 em Conjunto com o CMMIDEV v1.2, maio 2011. Disponvel em: www.softex.br. [PROCURE] - PROCURE - The Procurement Forums Special Interest Groups. Disponvel em http://www.imakenews.com/procurementforum/index000005275.cfm ltimo acesso em 31.01.05. [ROCHA, 2001] - ROCHA, Ana Regina. C.da, MALDONADO, Jos C.; WEBER, Kival C.. Qualidade de Software: Teoria e Prtica. 1. ed. So Paulo: Prentice Hall, 2001. 303 p. [SAMETINGER, 1997] - Sametinger, J., Software Engineering with Reusable Components, Springer, 1997. [SIMO, 2002] - Simo, R.P.S., Caractersticas de Qualidade para Componentes de Software, Tese de Mestrado, UNIFOR, Fortaleza, Cear, 2002. [TCU, 2006] - Tribunal de Contas da Unio. Acrdo 786/2006-TCU-Plenrio. Braslia, 2006. Disponvel em: <http://contas.tcu.gov.br/portaltextual/MostraDocumento?lnk=(acordao+adj+786/200 6+adj+plenario)[idtd][b001]>. Acesso em: 26 fev. 2011. [VOAS, 1998] - Voas, J. M., Certifying Off-the-Shelf Software Components, IEEE Computer, 0018-9162/98, 1998, June, pp 53-59.

MPS.BR-Guia de Aquisio:2011

91/96

Lista de colaboradores do Guia de Aquisio:2011 Editores: Danilo Scalet Edmeia Leonor Pereira de Andrade Revisor: Joo Condack PRIMEUP CELEPAR EMBRAPA

MPS.BR-Guia de Aquisio:2011

92/96

Lista de colaboradores do Guia de Aquisio:2009 Editor: Danilo Scalet Revisores: Ana Cervigni Guerra Ana Regina C Rocha Edmeia Leonor Pereira de Andrade Gleison dos Santos Souza Lcia Nigro Pereira Pinheiro Mariano Angel Montoni CTI COPPE/UFRJ (Coordenadora da ETM) EMBRAPA COPPE/UFRJ CASNAV (Marinha do Brasil) COPPE/UFRJ Ana Liddy Cenni de Castro Magalhes QualityFocus e Universidade FUMEC CELEPAR

MPS.BR-Guia de Aquisio:2011

93/96

Lista de colaboradores do Guia de Aquisio verso 1.2 Editor: Danilo Scalet Colaboradores: Ana Cervigni Guerra Edmeia Leonor Pereira de Andrade Lcia Nigro Pereira Pinheiro Regina Thienne Colombo Revisores: Francisco Vasconcellos Kival Chaves Weber Marinha do Brasil / COPPE/UFRJ SOFTEX CenPRA MAPA CASNAV (Marinha do Brasil) CenPRA CELEPAR

MPS.BR-Guia de Aquisio:2011

94/96

Lista de colaboradores do Guia de Aquisio verso 1.1 Editor: Danilo Scalet Colaboradores: Ana Cervigni Guerra ngela M. Alves Lcia Nigro Pereira Pinheiro Regina Thienne Colombo Revisores: Christiane Gresse von Wangenheim Clenio F. Salviano Cristina ngela Filipak Machado Fbio Nogueira de Lucena Francisco Vasconcellos Kathia Maral Oliveira Kival Chaves Weber Marcio Pecegueiro Amaral UNIVALI CenPRA CELEPAR UFG (Instituto de Informtica) Marinha do Brasil UCB SOFTEX RIOSOFT CenPRA CenPRA CASNAV (Marinha do Brasil) CenPRA CELEPAR

MPS.BR-Guia de Aquisio:2011

95/96

Lista de colaboradores do Guia de Aquisio verso 1.0 Editor: Danilo Scalet Colaboradores: Ana Cervigni Guerra ngela M. Alves Clnio F. Salviano Lcia Nigro Pereira Pinheiro Regina Thienne Colombo Revisores: Ana Cristina Rouiller Ana Cervigni Guerra Ana Regina C Rocha Andr Villas-Boas Clenio F. Salviano Eratstenes Arajo Kathia Maral Oliveira Kival Chaves Weber Marcio Pecegueiro Amaral UFLA CenPRA COPPE/UFRJ CPqD CenPRA SOFTEX UCB SOFTEX RIOSOFT CenPRA CenPRA CenPRA CASNAV (Marinha do Brasil) CenPRA CELEPAR

Cristina ngela Filipak Machado CELEPAR

Luiz Carlos de Almeida Oliveira CELEPAR

MPS.BR-Guia de Aquisio:2011

96/96