PROCESSO N.º /

Tamanho: px
Começar a partir da página:

Download "PROCESSO N.º 23036.002694/2011-79"

Transcrição

1 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS Quadra 701, Bloco M, Asa Sul, Ed. Sede do Inep, 2º Andar. CEP: CNPJ / (61) / 3240 / 3243 Fax EDITAL DO PREGÃO ELETRÔNICO N.º 32/2012. DTDIE/INEP PROCESSO N.º / OBJETO: prestação de serviços na área de Tecnologia da Informação para ASSESSORIA TECNOLÓGICA EM SISTEMAS DE INFORMAÇÃO visando prover a Diretoria de Tecnologia e Disseminação de Informações Educacionais (DTDIE) de capacidade organizacional para operacionalizar os serviços de TI e atender às necessidades tecnológicas do Inep que compreendem: ANÁLISE DE ARQUITETURA DE SISTEMAS e ANÁLISE DE NEGÓCIO PARA SISTEMAS, mediante ordens de serviço dimensionadas pela MÉTRICA PARA ASSESSORIA TECNOLÓGICA - MAT, limitada ao quantitativo máximo de até (MAT) anuais, sem garantia de consumo mínimo, pelo prazo de 12 (doze) meses, renováveis por iguais períodos até o limite de 60 (sessenta) meses. 1

2 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS Quadra 701, Bloco M, Asa Sul, Ed. Sede do Inep, 2º Andar. CEP: CNPJ / (61) / 3240 / 3235 Fax PREGÃO ELETRÔNICO Nº 32/2012 DTDIE/INEP PROCESSO N.º / O INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP, torna público, por intermédio de seu Pregoeiro, designado pela Portaria nº 434, de 13 de dezembro de 2011 e do seu Diretor, que fará realizar licitação, na modalidade PREGÃO ELETRÔNICO TIPO MENOR PREÇO GLOBAL, que será regido pela Lei nº , de 17 de julho de 2002, pelo Decreto nº 3.555, de 8 de agosto de 2000, alterado pelos Decretos nº 3.693, de 20 de dezembro de 2000 e nº 3.784, de 6 de abril de 2001, Decreto nº 5.450, de 31 de maio de 2005, Lei Complementar nº 123, de 2006, Decreto nº 6.204/2007, Decreto n 7.174/2010, Lei nº 8.078/90 Código de Defesa do Consumidor, IN-MPOG nº 02, de 30 de abril de 2008, e suas alterações posteriores, IN-MPOG nº 4, de 12 de novembro de 2010, IN-MPOG nº 01, de 20 de janeiro de 2010, e demais legislações correlatas, aplicando-se subsidiariamente, no que couber, as disposições da Lei nº 8.666, de 21 de junho de 1993, com suas alterações, mediante as condições e exigências estabelecidas neste Edital e nos anexos que o integram. Data: 11 de dezembro de 2012 Horário: 10 horas Endereço eletrônico: 2

3 1. DO OBJETO 1.1. A presente licitação tem por objeto a contratação de prestação de serviços na área de Tecnologia da Informação para ASSESSORIA TECNOLÓGICA EM SISTEMAS DE INFORMAÇÃO visando prover a Diretoria de Tecnologia e Disseminação de Informações Educacionais (DTDIE) de capacidade organizacional para operacionalizar os serviços de TI e atender às necessidades tecnológicas do Inep que compreendem: ANÁLISE DE ARQUITETURA DE SISTEMAS e ANÁLISE DE NEGÓCIO PARA SISTEMAS, mediante ordens de serviço dimensionadas pela MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT, limitada ao quantitativo máximo de até (MAT) anuais, sem garantia de consumo mínimo, conforme quantidade e especificações mínimas do Termo de Referência e seus Anexos Constituem Anexos a este Edital, dele fazendo parte integrante como se transcritos estivessem: a) Termo de Referência Anexo I e seus Anexos: i. Anexo A Portfólio de Atividades e Artefatos; ii. iii. iv. Anexo B Modelo de Ordem de Serviço; Anexo C Modelo de Ordem de Serviço de Garantia; Anexo D Relatório de Execução de Serviço; v. Anexo E Indicadores de Níveis de Serviço; vi. vii. viii. ix. Anexo F Modelo do Relatório para Pagamento; Anexo G Quadro de Recursos de TI; Anexo H Relação de Sistemas que compõem o Legado do Inep; Anexo I Termo de Credenciamento; x. Anexo J Modelo do Termo de Descredenciamento; xi. xii. xiii. xiv. xv. xvi. xvii. xviii. Anexo K Modelo do Termo de Confidencialidade; Anexo L Modelo do Termo de Ciência; Anexo M Termo de Realização de Vistoria Técnica; Anexo N Termo de Compromisso; Anexo O Planilha de Custos e Formação de Preços; Anexo P Perfis Profissionais e Formação Exigida; Anexo Q Quadro de Recursos Técnicos; Anexo R MGDS e Guias Adotadas pelo Inep; 3

4 b) Declaração de Elaboração Independente de Proposta Anexo II c) Minuta do Contrato Anexo III 2. DA QUALIFICAÇÃO DAS MICROEMPRESAS E DAS EMPRESAS DE PEQUENO PORTE PARA FRUIÇÃO DOS BENEFÍCIOS PREVISTOS NA LEI COMPLEMENTAR Nº 123, DE 14 DE DEZEMBRO DE 2006 E SUAS ALTERAÇÕES E DO DECRETO Nº 6.204, DE 5 DE SETEMBRO DE No ato de envio de sua proposta, em campo próprio do sistema, a microempresa e a empresa de pequeno porte deverá declarar, sob as penas da Lei, que cumprem os requisitos estabelecidos no Art. 3º da Lei Complementar nº 123, de 14 de dezembro de 2006, alterada pela Lei nº , de 15 de junho de 2007, em seu Art. 34, que essa Empresa está apta a usufruir do tratamento favorecido estabelecido nos artigos 42 ao 49 da referida Lei Complementar Para os efeitos deste Edital, consideram-se microempresas ou empresas de pequeno porte a sociedade empresária, a sociedade simples e o empresário a que se refere o art. 966 da Lei no , de 10 de janeiro de 2002, devidamente registrados no Registro de Empresas Mercantis ou no Registro Civil de Pessoas Jurídicas, conforme o caso, desde que: I - No caso das microempresas, o empresário, a pessoa jurídica, ou a ela equiparada, aufira, em cada ano-calendário, receita bruta igual ou inferior a R$ ,00 (trezentos e sessenta mil reais); II - No caso das empresas de pequeno porte, o empresário, a pessoa jurídica, ou a ela equiparada, aufira, em cada ano-calendário, receita bruta superior a R$ ,00 (trezentos e sessenta mil reais) e igual ou inferior a R$ ,00 (três milhões e seiscentos mil reais) Não fará jus ao regime diferenciado e favorecido previsto no art. 42 e seguintes da Lei Complementar nº 123, de 14 de dezembro de 2006, a microempresa ou empresa de pequeno porte: I - De cujo capital participe outra pessoa jurídica; II - Que seja filial, sucursal, agência ou representação, no País, de pessoa jurídica com sede no exterior; III - De cujo capital participe pessoa física que seja inscrita como empresário, ou seja sócia de outra empresa que receba tratamento jurídico diferenciado nos termos desta Lei Complementar, desde que a receita bruta global ultrapasse o limite de que trata o inciso II do caput do art. 3º da Lei Complementar nº 123, de 14 de dezembro de 2006; IV - Cujo titular ou sócio participe com mais de 10% (dez por cento) do capital de outra empresa não beneficiada por esta Lei Complementar, desde que a receita bruta global ultrapasse o limite de que trata o inciso II do caput do art.3º da Lei Complementar nº 123, de 14 de dezembro de 2006; 4

5 V - Cujo sócio ou titular seja administrador ou equiparado de outra pessoa jurídica com fins lucrativos, desde que a receita bruta global ultrapasse o limite de que trata o inciso II do caput do art. 3º da Lei Complementar nº 123, de 14 de dezembro de 2006; VI - Constituída sob a forma de cooperativas, salvo as de consumo; VII - Que participe do capital de outra pessoa jurídica; VIII - Que exerça atividade de banco comercial, de investimentos e de desenvolvimento, de caixa econômica, de sociedade de crédito, financiamento e investimento ou de crédito imobiliário, de corretora ou de distribuidora de títulos, valores mobiliários e câmbio, de empresa de arrendamento mercantil, de seguros privados e de capitalização ou de previdência complementar; IX - Resultante ou remanescente de cisão ou qualquer outra forma de desmembramento de pessoa jurídica que tenha ocorrido em um dos 05 (cinco) anos-calendário anteriores; X - Constituída sob a forma de sociedade por ações O Sistema verificará automaticamente junto à Receita Federal o porte da Empresa que atende os requisitos do artigo 3º da Lei Complementar nº 123/ DA IMPUGNAÇÃO DO EDITAL E DOS PEDIDOS DE ESCLARECIMENTOS 3.1. Até dois dias úteis antes da data fixada para abertura da sessão pública, qualquer pessoa poderá impugnar o ato convocatório do Pregão, na forma eletrônica. (Art.18 do Decreto nº 5.450/2005); 3.2. Caberá ao Pregoeiro, auxiliado pelo setor responsável pela elaboração do edital, decidir sobre a impugnação no prazo de até vinte e quatro horas (Art.18, 1º do Decreto nº 5.450/2005); 3.3. Acolhida a impugnação contra o ato convocatório, será definida e publicada nova data para realização do certame. (art.18, 2º do Decreto nº 5.450/2005) As impugnações deverão ser apresentadas exclusivamente na forma eletrônica, através do até às 18hs, do segundo dia útil anterior à data fixada para abertura da sessão pública Os pedidos de esclarecimentos referentes ao processo licitatório deverão ser enviados ao Pregoeiro, até às 18hs do terceiro dia útil anterior à data fixada para abertura da sessão pública, exclusivamente por meio eletrônico via Internet, no (Art.19 do Decreto nº 5.450/2005) As respostas às impugnações e aos esclarecimentos solicitados serão disponibilizadas no endereço eletrônico por meio do link Acesso livre > Pregões > Agendados, para conhecimento da sociedade em geral e dos fornecedores, cabendo aos interessados em participar do certame acessá-lo para a obtenção das informações prestadas. 5

6 4. DA MODIFICAÇÃO DO EDITAL Qualquer modificação no presente Edital será divulgada pela mesma forma que se divulgou o texto original, reabrindo-se o prazo inicialmente estabelecido, exceto quando, inquestionavelmente, a alteração não afetar a formulação da proposta. 5. DAS CONDIÇÕES GERAIS PARA PARTICIPAÇÃO 5.1. Poderão participar deste Pregão os interessados que: a) Pertençam ao ramo de atividade do objeto licitado e atendam às condições deste Edital e de seus Anexos, inclusive quanto à documentação, e estejam devidamente credenciadas na Secretaria de Logística e Tecnologia da Informação (SLTI), do Ministério do Planejamento, Orçamento e Gestão, por meio do sítio para acesso ao sistema eletrônico; e b) Atenderem a todas as exigências constantes deste Edital e que estejam devidamente CADASTRADAS e HABILITADAS PARCIALMENTE no Sistema de Cadastramento Unificado de Fornecedores SICAF; 5.2. Os interessados não cadastrados no SICAF, e que tiverem interesse em participar do presente Pregão, deverão providenciar o seu cadastramento e sua habilitação junto a qualquer Unidade Cadastradora dos órgãos da Administração Pública, até o terceiro dia útil anterior à data da abertura da sessão (Parágrafo único do art. 3º do Decreto nº 3.722/01 c/c o Parágrafo único do Art. 14 do Decreto nº 5.450/2005); 5.3. NÃO PODERÃO CONCORRER, DIRETA OU INDIRETAMENTE, NESTA LICITAÇÃO: a) Empresas em estado de falência, de concurso de credores, de dissolução ou liquidação e em recuperação judicial e extrajudicial; b) Empresas que tenham sido declaradas inidôneas por qualquer órgão/entidade da Administração Pública, direta ou indireta, federal, estadual ou municipal, bem como as que estejam punidas com suspensão do direito de contratar ou licitar com a Administração Pública Federal; c) Empresas reunidas em consórcio e/ou que sejam controladoras, coligadas ou subsidiárias entre si; d) Servidor de qualquer órgão ou entidade vinculada à entidade promotora da licitação, bem assim a empresa da qual tal servidor seja sócio, dirigente ou responsável técnico; e) Empresas estrangeiras que não funcionem no País; f) Sociedades Cooperativas; g) Empresas que possuem contratos de prestação de serviços ou fornecimento de recursos de Tecnologia da Informação em vigência com o Inep, conforme disposto no art.6 da Instrução Normativa Nº 04 de 12 de novembro de 2010/ SLTI-MP. 6

7 6. DO CREDENCIAMENTO 6.1. Deverão ser previamente credenciados perante o provedor do sistema eletrônico a autoridade competente da entidade promotora da licitação, o Pregoeiro, os membros da equipe de apoio e os licitantes que participam do Pregão na forma eletrônica. (Art. 3º do Decreto nº 5.450/2005) O credenciamento dar-se-á pela atribuição de chave de identificação e de senha, pessoal e intransferível, para acesso ao sistema eletrônico (Art. 3º, 1º, do Decreto nº 5.450/2005), no sítio O credenciamento do(s) licitante(s) dependerá de registro atualizado no Sistema de Cadastramento Unificado de Fornecedores SICAF, que também será requisito obrigatório para sua habilitação. (Art. 3º, 2º, do Decreto nº 5.450/2005) O uso da senha de acesso pelo licitante é de sua responsabilidade exclusiva, incluindo qualquer transação efetuada diretamente ou por seu representante, não cabendo ao provedor do sistema ou ao INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANISIO TEIXEIRA - INEP, promotor da licitação, responsabilidade por eventuais danos decorrentes do uso indevido da senha, ainda que por terceiros. (Art.3º, 5º, do Decreto nº 5.450/2005) O credenciamento junto ao provedor do sistema implica responsabilidade legal do licitante ou de seu representante legal e a presunção de sua capacidade técnica para realização das transações inerentes ao Pregão Eletrônico (Art. 3º, 6º, do Decreto nº 5.450/2005). 7. DO ENVIO DA PROPOSTA DE PREÇOS 7.1. Após a divulgação do Edital no sítio os licitantes deverão encaminhar suas propostas com a descrição do objeto ofertado e os preços com valores unitários e totais do item, o(s) respectivo(s) anexo(s), até a data e hora marcadas para abertura da sessão, ou seja, até as 10 horas do dia 11 de dezembro de 2012, horário de Brasília, exclusivamente por meio do sistema eletrônico, quando, então, encerrar-se-á, automaticamente, a fase de recebimento de propostas. A proposta será analisada pelo Pregoeiro, que desclassificará as propostas em desconformidade com o Edital e seus Anexos. (Art. 21 e 2º do Art. 22, do Decreto nº 5.450/2005) A participação no Pregão Eletrônico dar-se-á pela utilização da senha privativa do licitante (Art. 21, 1º, do Decreto nº 5.450/2005) Para participação no Pregão Eletrônico, o licitante deverá manifestar, em campo próprio do sistema eletrônico, que cumpre plenamente os requisitos de habilitação e que sua proposta está em conformidade com as exigências do instrumento convocatório (Art. 21, 2º, do Decreto nº 5.450/2005) A declaração falsa relativa ao cumprimento dos requisitos de habilitação e proposta sujeitará o licitante à sanção prevista neste Edital e no Decreto nº 5.450/2005, nos termos do Art. 21, 3º, do Decreto nº 5.450/

8 7.5. As declarações de que tratam os subitens e , deste Edital, serão enviadas, de forma virtual, no momento da elaboração e envio da proposta, as quais somente serão visualizadas pelo pregoeiro na fase de habilitação, quando também poderão ser alteradas ou reenviadas pelos licitantes, por solicitação do pregoeiro Até a abertura da sessão, o licitante poderá retirar ou substituir a proposta anteriormente apresentada, nos termos do Art. 21, 4º, do Decreto nº 5.450/ O licitante responsabilizar-se-á formalmente pelas transações efetuadas em seu nome, assumindo como firmes e verdadeiras suas propostas e lances, inclusive os atos praticados diretamente ou por seu representante, não cabendo ao provedor do sistema ou ao promotor da licitação, responsabilidade por eventuais danos decorrentes de uso indevido da senha, ainda que por terceiros. (Art.13, Inciso III, do Decreto nº 5.450/2005) Incumbirá ao licitante acompanhar as operações no sistema eletrônico durante a sessão pública do Pregão, ficando responsável pelo ônus decorrente da perda de negócios diante da inobservância de quaisquer mensagens emitidas pelo sistema ou de sua desconexão (Art. 13, Inciso IV, do Decreto nº 5.450/2005) A proposta deverá ser apresentada contendo no mínimo: Especificação clara e completa do objeto oferecido, obedecida preferencialmente a mesma ordem constante no TERMO DE REFERÊNCIA, devendo conter o detalhamento de todas as características dos serviços ofertados, assim como a especificação da garantia dos serviços e dos prazos de execução PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS que contenha as especificações detalhadas dos serviços, conforme modelo presente no Anexo O do Termo de Referência, em moeda corrente nacional, expresso em algarismos e por extenso nos valores unitários e totais dos serviços ofertados Prazo de validade mínima da proposta que deverá ser de 60 (sessenta) dias, a contar da data de sua apresentação Declaração expressa de que os preços contidos na proposta incluem todos os custos, despesas e encargos A razão social, o CNPJ, colocando o número do Edital do Pregão, dia e hora de abertura, endereço completo, o número do telefone, fax e , bem como, o número de sua conta corrente, o nome do Banco e a respectiva Agência onde deseja receber seus créditos, não sendo fator de desclassificação o descumprimento deste item Apresentar quaisquer outras informações afins que julgar necessárias ou convenientes, não sendo fator de desclassificação o descumprimento deste item As empresas licitantes deverão apresentar, juntamente com a Proposta de Preços, o TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA- Anexo M do Termo de Referência devidamente preenchido e assinado por responsável da 8

9 DTDIE, afirmando que a licitante visitou as dependências do Inep, onde serão prestados os serviços, tomando conhecimento de todos os aspectos que possam influir direta ou indiretamente na execução dos mesmos As empresas licitantes deverão apresentar, juntamente com a Proposta de Preços, o QUADRO DE RECURSOS TÉCNICOS - Anexo Q do Termo de Referência, devidamente preenchido e assinado, composto dos quantitativos de recursos técnicos que pretende utilizar in loco, distribuídos por áreas de atuação previstas para este TERMO DE REFERÊNCIA, e respectivas remunerações mensais de cada grupo Todos os requisitos técnicos deverão ser indicados na documentação técnica (incluindo número da página e sua respectiva fonte) A apresentação da proposta implicará em PLENA ACEITAÇÃO, por parte do proponente, das condições estabelecidas. 8..DA RECEPÇÃO, JULGAMENTO E DIVULGAÇÃO DAS PROPOSTAS A partir das 10 horas do dia 11 de dezembro de 2012, data e horário previstos no preâmbulo deste Edital, terá início a sessão pública do Pregão Eletrônico nº 32/2012, com a divulgação e julgamento das Propostas de Preços recebidas e início da etapa de lances, conforme Edital e de acordo com o Decreto nº 5.450/ No julgamento das Propostas serão observadas as especificações constantes deste Edital e seus Anexos Será verificada a conformidade das Propostas apresentadas com os requisitos estabelecidos neste Edital e seus Anexos A classificação das propostas será pelo critério do TIPO MENOR PREÇO GLOBAL tomando-se como base na PLANILHA DE CUSTO E FORMAÇÃO DE PREÇOS do ENCARTE O DO TERMO DE REFERÊNCIA parte integrante deste Edital Serão desclassificadas as propostas que: a) Não atenderem às exigências do presente Edital e seus Anexos; b) Apresentarem valores simbólicos, irrisórios, inexeqüíveis ou excessivos, consideradas as condições já dispostas neste Edital e seus Anexos; e c) Apresentarem propostas alternativas A desclassificação da proposta será fundamentada e registrada no sistema Somente os licitantes com propostas classificadas participarão da fase de lances O Pregoeiro poderá solicitar parecer(es) técnico(s), para orientar sua(s) decisão(ões) Serão consideradas propostas com indícios de inexeqüibilidade aquelas cujo valor unitário apresentado por MÉTRICA PARA ASSESSORIA TECNOLÓGICA - MAT seja inferior a 70% do menor entre os seguintes valores: 9

10 o Preço orçado pelo Inep; o Média aritmética dos valores das propostas superiores a 50% do preço orçado pelo Inep Caso a proposta de menor preço apresente indício de inexequibilidade de acordo com o critério acima, será facultado à licitante comprovar a exequibilidade de sua proposta. Após análise da comprovação oferecida, e permanecendo dúvidas quanto à exequibilidade da proposta, o Inep poderá promover diligência para aferir a legalidade e exequibilidade da proposta, conforme previsto no 3º do art. 29 da Instrução Normativa MPOG nº 2 de 30 de abril de Caso a licitante não apresente a comprovação de exequibilidade, ou o resultado da diligência indique incapacidade de execução, a proposta correspondente será desclassificada do certame. 9. DA FORMULAÇÃO DOS LANCES 9.1. Classificadas as Propostas, o Pregoeiro dará início à fase competitiva, quando então os licitantes poderão encaminhar lances exclusivamente por meio do sistema eletrônico. (Art. 24, do Decreto nº 5.450/2005) Assim como as propostas, os lances serão ofertados pelo MENOR PREÇO GLOBAL, incluídos todos os custos incidentes; e Não poderá haver desistência dos lances ofertados, sujeitando-se o proponente desistente às sanções administrativas constantes neste Edital Os licitantes poderão oferecer lances sucessivos, observados o horário fixado para abertura da sessão pública e as regras estabelecidas neste Edital O licitante somente poderá oferecer lance inferior ao último por ele ofertado e registrado pelo sistema Havendo mais de um lance de igual valor, prevalecerá aquele que for recebido e registrado em primeiro lugar Durante o transcurso da sessão pública, os licitantes serão informados, em tempo real, do valor do menor lance registrado que tenha sido apresentado pelos demais licitantes, vedada a identificação do licitante No caso de desconexão do Pregoeiro, no decorrer da etapa de lances, se o sistema eletrônico permanecer acessível aos licitantes, os lances continuarão sendo recebidos, sem prejuízo dos atos realizados. (Art.24, 10, do Decreto nº 5.450/2005) Quando a desconexão do Pregoeiro persistir por tempo superior a 10 (dez) minutos, a sessão do Pregão será suspensa e terá reinício somente após comunicação expressa do Pregoeiro aos participantes, no sítio (Art.24, 11, do Decreto nº 5.450/2005). 10

11 No caso de desconexão do licitante proponente, este deverá de imediato, sob sua inteira responsabilidade, providenciar sua conexão ao sistema A etapa de lances da sessão pública será encerrada, por decisão do Pregoeiro, mediante aviso de fechamento iminente dos lances, emitido pelo sistema eletrônico aos licitantes, após o que transcorrerá período de tempo de até 30 (trinta) minutos, aleatoriamente determinado pelo sistema eletrônico, findo o qual será automaticamente encerrada a recepção de lances. 10. DA PREFERÊNCIA EM FAVOR DAS MICROEMPRESAS E DAS EMPRESAS DE PEQUENO PORTE (LEI COMPLEMENTAR Nº 123, DE 14 DE DEZEMBRO 2006) E DOS FORNECEDORES DE BENS E SERVIÇOS, DISPOSTO NO ART. 3º DA LEI Nº 8.248, DE Após o encerramento da etapa de lances, o SISTEMA DE PREGÃO ELETRÔNICO COMPRASNET IDENTIFICARÁ EM COLUNA PRÓPRIA AS ME/EPP PARTICIPANTES, FAZENDO A COMPARAÇÃO ENTRE OS VALORES DA PRIMEIRA COLOCADA, CASO ESTA NAO SEJA UMA ME/EPP, E DAS DEMAIS ME/EPPS NA ORDEM DE CLASSIFICAÇÃO Considerar-se-ão empatados todos os lances apresentados pelas microempresas e empresas de pequeno porte que atenderam subitem 2.1, deste Edital, que sejam iguais ou até 5% (cinco por cento) superiores ao lance mais bem classificado Não ocorrerá empate quando o melhor lance tiver sido apresentado por microempresa ou empresa de pequeno porte que atendeu o subitem 2.1, deste Edital Ocorrendo empate, nos termos do subitem 10.2, do Edital: I) A proposta que se encontrar na faixa ate 5% acima da proposta de menor preço estará empatada com a primeira colocada e terá o direito, no prazo de 5 (cinco) minutos controlados pelo sistema, de encaminhar uma última oferta, obrigatoriamente abaixo da primeira colocada para o desempate. II) Para viabilizar tal procedimento, o sistema selecionará os itens com tais características, disponibilizando-os automaticamente nas telas do pregoeiro e fornecedor, encaminhando mensagem também automática, por meio do Chat, convocando a ME/EPP que se encontra em segundo lugar, a fazer sua última oferta no prazo de 5 (cinco) minutos sob pena de decair do direito concedido. III) Caso a ME/EPP classificada em segundo lugar desista ou não se manifeste no prazo estabelecido, o sistema convocara as demais ME/EPPS participantes na mesma condição, na 11

12 ordem de classificação. Havendo êxito neste procedimento, o sistema disponibilizará a nova classificação dos fornecedores para fins de aceitação. classificação inicial. IV) Não havendo êxito, ou não existindo ME/EPP participante, prevalecerá a V) Caso sejam identificadas propostas de ME/EPP empatadas em segundo lugar, ou seja, na faixa dos 5% da primeira colocada, e permanecendo o empate até o encerramento do item, o sistema fará um sorteio eletrônico entre tais fornecedores, definindo e convocando automaticamente a vencedora para o encaminhamento da oferta final do desempate. VI) A negociação de preço junto ao fornecedor classificado em primeiro lugar, quando houver, será sempre após o procedimento de desempate de propostas e classificação final dos fornecedores participantes. Os demais procedimentos ou fases permanecem inalterados Anunciado o vencedor, o Pregoeiro poderá encaminhar pelo sistema eletrônico contraproposta diretamente ao licitante que tenha apresentada a oferta mais vantajosa, para que seja obtida a melhor proposta, observado o critério de julgamento, não se admitindo negociar condições diferentes daquelas previstas no Edital, bem assim decidir sobre sua aceitação A negociação será realizada por meio do sistema, podendo ser acompanhada pelos demais licitantes Também será assegurada preferência na contratação, nos termos do disposto no art. 3º da Lei nº 8.248, de 1991, regulado pelo art. 5º, do Decreto nº 7.174/2010, observada a seguinte ordem: I) bens e serviços com tecnologia desenvolvida no País e produzidos de acordo com o Processo Produtivo Básico (PPB), na forma definida pelo Poder Executivo Federal; II) bens e serviços com tecnologia desenvolvida no País; e III) bens e serviços produzidos de acordo com o PPB, na forma definida pelo Poder Executivo Federal As microempresas e empresas de pequeno porte que atendam ao disposto nos incisos acima terão prioridade no exercício do direito de preferência em relação às médias e grandes empresas enquadradas no mesmo inciso O exercício do direito de preferência disposto nos subitens 10.2 e 10.6, será concedido, observando-se os seguintes procedimentos, sucessivamente: 12

13 a) aplicação das regras de preferência para as microempresas e empresas de pequeno porte dispostas no subitem 10.3, quando for o caso; b) aplicação das regras de preferência previstas no subitem 10.6, com a classificação dos licitantes cujas propostas finais estejam situadas até dez por cento acima da melhor proposta válida, conforme o critério de julgamento, para a comprovação e o exercício do direito de preferência; c) convocação dos licitantes classificados que estejam enquadrados no inciso I subitem 10.6, na ordem de classificação, para que possam oferecer nova proposta ou novo lance para superar a melhor proposta válida, caso em que será declarado vencedor do certame; d) caso a preferência não seja exercida na forma da alínea c, por qualquer motivo, serão convocadas as empresas classificadas que estejam enquadradas no inciso II do subitem 10.6, na ordem de classificação, para a comprovação e o exercício do direito de preferência, aplicando-se a mesma regra para o inciso III do subitem 10.6, caso esse direito não seja exercido A comprovação do atendimento ao PPB será feita mediante apresentação do documento comprobatório da habilitação à fruição dos incentivos fiscais regulamentados pelo Decreto no 5.906, de 26 de setembro de 2006, ou pelo Decreto no 6.008, de 29 de dezembro de A comprovação será feita: I - eletronicamente, por meio de consulta ao sítio eletrônico oficial do Ministério da Ciência e Tecnologia ou da Superintendência da Zona Franca de Manaus - SUFRAMA; ou II - por documento expedido para esta finalidade pelo Ministério da Ciência e Tecnologia ou pela SUFRAMA, mediante solicitação da licitante Na hipótese em que nenhuma das licitantes preencha os requisitos elencados no subitem 10.6, prevalecerá o resultado inicialmente apurado pelo sistema eletrônico. 11. DO ENVIO DAS PROPOSTAS DE PREÇOS READEQUADAS AO LANCE VENCEDOR Após o encerramento da etapa de lances e, o licitante classificado em primeiro lugar deverá, no prazo de 24 (vinte e quatro) horas, encaminhar, por meio do fax (0xx61) , sua proposta de preços readequada à oferta vencedora, com posterior encaminhamento da original ao Pregoeiro, no prazo máximo de 3 dias úteis. ( 6º do Art. 25 do Decreto nº 5.450/2005) O proponente que não atender o disposto no subitem anterior será desclassificado Caso haja a desclassificação da licitante mais bem classificada, o pregoeiro chamará, via Chat, o(s) próximo(s) licitante(s) para confirmar o envio de sua proposta conforme o subitem 11.1; O licitante que não responder ao chamamento a que se refere o subitem anterior, no prazo estipulado pelo pregoeiro via Chat, será desclassificado. 13

14 12. DA HABILITAÇÃO A habilitação do licitante será verificada por meio do SICAF, nos documentos por ela abrangidos, e por meio da documentação complementar especificada neste Edital A licitante que estiver com alguma restrição na comprovação da regularidade fiscal, ressalvado o que trata o subitem 12.2, será desclassificada Havendo alguma restrição na comprovação da regularidade fiscal das microempresas ou das empresas de pequeno porte, será concedido um prazo de 02 (dois) dias úteis, contados do momento em que o licitante foi declarado vencedor do certame, prorrogáveis por igual período, para a regularização da documentação, pagamento ou parcelamento do débito, e emissão de eventuais certidões negativas ou positivas com efeito de certidão negativa Antes de ser efetivada a contratação, da licitante vencedora, deverá ser realizada consulta junto ao SICAF, SIAFI e CADIN, para verificação da regularidade da licitante A prorrogação do prazo para regularização fiscal será concedida pelo Inep quando requerida pelo licitante, a não ser que exista urgência na contratação ou prazo insuficiente para o empenho; A não-regularização da documentação fiscal, no prazo previsto no subitem anterior, implicará decadência do direito à contratação, sem prejuízo das sanções previstas no art. 81, da Lei n , de 21 de junho de 1993, sendo facultado ao INEP convocar os licitantes remanescentes, na ordem de classificação, ou revogar a licitação A existência de qualquer outra restrição na habilitação da licitante diversa da regularidade fiscal ensejará a desclassificação imediata da proponente Para fins de habilitação, todos os licitantes deverão apresentar, ainda, a seguinte documentação complementar: TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA- Anexo M do Termo de Referência, assinado pela equipe técnica da DTDIE do Inep, declarando ter conhecimento da plataforma atualmente instalada, locais de realização dos serviços, instalações de infraestrutura, condições ambientais e locais para acomodação da equipe CONTRATADA; A vistoria técnica deverá ocorrer por horário marcado, e será agendada pela DTDIE através do telefone (61) ; O agendamento de vistoria poderá ocorrer até 48 (quarenta e oito) horas antes da data e horário de abertura do processo licitatório; A vistoria técnica deverá ser realizada em até 24 (vinte e quatro) horas antes da abertura do processo licitatório ATESTADO(S) DE CAPACIDADE TÉCNICA, fornecido(s) por pessoa jurídica de direito público ou privado comprovando a experiência na execução de 14

15 serviços de ASSESSORIA TECNOLÓGICA EM SISTEMAS DE INFORMAÇÃO E PROCESSOS totalizando, no mínimo, (dez mil) horas de serviços de Análise de Arquitetura de Sistemas, e/ou Análise de Negócio para Sistemas Os ATESTADO(S) DE CAPACIDADE TÉCNICA, com a discriminação do nome de cada órgão/empresa emitente, comprovando a efetiva execução dos serviços e informações prestadas pela licitante e elaborados em papel timbrado da empresa emitente, contendo os seguintes dados mínimos e obrigatórios: - Razão Social, CNPJ e Endereço Completo da Empresa Emitente; - Razão Social da Licitante; - Referência do Contrato; ; - Vigência do Contrato: De / / a / / ; - Objeto do Contrato; - Descrição do Objeto do Contrato (descrição detalhada dos serviços prestados); - Local e Data de Emissão do Atestado; - Nome e Assinatura do Signatário, Cargo, Telefone para contato e Fax. - Descrição detalhada de todo o serviço prestado; - Total de horas prestadas Apresentar o QUADRO DE RECURSOS TÉCNICOS - Anexo Q, devidamente preenchido, composto dos quantitativos de recursos técnicos que pretende utilizar in loco, distribuídos por áreas de atuação previstas para este TERMO DE REFERÊNCIA, e respectivas remunerações mensais de cada grupo CRITÉRIO TÉCNICO OBRIGATÓRIO - A empresa deverá apresentar termo de conhecimento das atividades relacionadas nos anexos e demais condições vistoriadas, declarando ter capacitação técnica para atender a todos os requisitos especificados no Edital A critério da Administração poderá ser necessário diligenciar a pessoa jurídica indicada no ATESTADO(S) DE CAPACIDADE TÉCNICA, visando obter informações sobre o serviço prestado É vedada a participação de empresas em consórcio O(s) ATESTADO(S) DE CAPACIDADE TÉCNICA, documentações e comprovações necessárias para que a administração certifique a veracidade das informações deverão conferir com o CNPJ e razão social da empresa licitante. 15

16 No caso de atestados emitidos por empresa da iniciativa privada, não serão considerados aqueles emitidos por empresas pertencentes ao mesmo grupo empresarial da empresa proponente. Serão considerados como pertencentes ao mesmo grupo empresarial da empresa proponente, empresas controladas ou controladoras da empresa proponente, ou que tenha pelo menos uma mesma pessoa física ou jurídica que seja sócio da empresa emitente e da empresa proponente Declaração, nos moldes do Anexo IV da IN do extinto MARE nº 05/95, republicada com alterações no Diário Oficial da União de 19/04/96, de que não há fato impeditivo de sua habilitação, obrigando-se a informar a superveniência de ocorrências posteriores; Declaração em cumprimento ao disposto no inciso XXXIII, do art. 7º, da Constituição Federal; Declaração nos moldes do Anexo II deste Edital, em cumprimento à Instrução Normativa nº 02, de 16 de setembro de 2009, publicada no DOU, nº 178, seção 1, página 80, de 17 de setembro de 2009; Para fins de habilitação, a verificação em sítios oficiais de órgãos e entidades emissores de certidões constitui meio legal de prova Os documentos necessários à habilitação os que não estejam contemplados no SICAF ou os necessários à atualização ou regularização dos dados constantes do SICAF bem como a Proposta de Preços vencedora ajustada ao lance dado serão imediatamente encaminhados ao Pregoeiro, no prazo máximo de 24 (vinte e quatro) horas contadas a partir do encerramento da etapa de lances, para o Fax (0XX61) , com posterior envio do original ou cópia autenticada (via SEDEX ou pessoalmente), no prazo máximo de 3 (três) dias úteis, ao seguinte endereço: INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA - COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS - SRTVS Quadra 701, Bloco M, Asa Sul, Ed. Sede do Inep, 2º Andar. CEP: Brasília-DF Tels: (61) / 3240 / 3235 Fax O envelope deverá ser identificado da seguinte maneira: PREGÃO ELETRÔNICO Nº 32/2012 DTDIE/INEP RAZÃO SOCIAL E CNPJ PROPOSTA E DOCUMENTOS DE HABILITAÇÃO Será considerada na apuração do prazo de encaminhamento do original da Proposta e da documentação, a data de postagem dos referidos documentos Os documentos encaminhados para habilitação deverão estar em nome do licitante, e, preferencialmente, com o número do CNPJ e o respectivo endereço. 16

17 12.7. Se o licitante for à própria matriz, todos os documentos deverão estar em nome da matriz. Sendo o licitante filial, todos os documentos deverão estar em nome da filial, exceto aqueles documentos que, pela própria natureza ou por força de Lei, comprovadamente somente possam ser emitidos em nome da matriz Os documentos necessários à habilitação poderão ser apresentados em original, ou qualquer processo de cópia autenticada através de cartório competente ou publicação em órgão da imprensa oficial Não serão aceitos protocolos de entrega ou solicitação de documento em substituição aos documentos requeridos no presente Edital e seus Anexos Documentos apresentados com a validade expirada acarretarão a inabilitação do proponente. Os documentos que não possuírem prazo de validade, somente serão aceitos com data não excedente a 30 (trinta) dias de antecedência da data prevista para apresentação das propostas, ressalvado aqueles que por sua característica não se sujeitam a prazo de validade. (Exemplo: Atestado de Capacidade Técnica) Na assinatura do Contrato, será exigida a comprovação das condições de habilitação consignadas no edital, as quais deverão ser mantidas pelo licitante durante a vigência do contrato O vencedor da licitação que não fizer a comprovação referida no subitem anterior ou quando, injustificadamente, recusar-se a assinar o contrato, poderá ser convocado outro licitante, desde que respeitada a ordem de classificação, para, após comprovados os requisitos habilitatórios e feita a negociação, assinar o contrato, sem prejuízos das multas previstas em edital e no contrato e das demais cominações legais Serão inabilitados os licitantes que não atenderem às exigências deste item. 13. DOS RECURSOS Declarado o vencedor, qualquer licitante poderá, durante a sessão pública, de forma imediata e motivada, em campo próprio do sistema, manifestar sua intenção de recorrer, quando lhe será concedido o prazo de 3 (três) dias para apresentar as razões de recurso, ficando os demais licitantes, desde logo, intimados para, querendo, apresentarem contra-razões em igual prazo, que começará a contar do término do prazo do recorrente A falta de manifestação imediata e motivada do licitante quanto à intenção de recorrer, nos termos do subitem 13.1 deste Edital, importará na decadência desse direito, ficando o Pregoeiro autorizado a adjudicar o objeto ao licitante declarado vencedor (Art.26, 1º, do Decreto nº 5.450/2005) O acolhimento de recurso importará na invalidação apenas dos atos insuscetíveis de aproveitamento (Art.26, 2º, do Decreto nº 5.450/2005) Não serão conhecidos os recursos interpostos sem manifestação prévia no ato da sessão pública, em campo próprio do sistema e fora dos respectivos prazos legais, 17

18 13.5. Os autos do processo permanecerão com vista franqueada aos interessados, no SRTVS Quadra 701, Bloco M, Asa Sul, Ed. Sede do Inep, 2º Andar. CEP: , em Brasília-DF, nos dias úteis, no horário de 09:00 às 12:00 horas e de 14:00 às 17:00 horas. 14. DA ADJUDICAÇÃO E HOMOLOGAÇÃO A adjudicação do objeto deste certame caberá ao Pregoeiro, quando não houver recurso. Existindo recurso hierárquico, o objeto será adjudicado pela autoridade competente para o seu julgamento A homologação da licitação é de responsabilidade da autoridade competente e só poderá ser realizada depois da adjudicação do objeto ao licitante vencedor. 15. DAS CONDIÇÕES E PRAZO DE PAGAMENTO 15.1 O procedimento de pagamento deverá obedecer aos seguintes passos: Serão consideradas para o pagamento as Ordens de Serviço CONCLUÍDAS que obtiveram indicação de ACEITO pelo FISCAL REQUISITANTE até o dia 20 (vinte) de cada mês Será considerado como VOLUME MENSAL o cálculo do somatório das MAT, em unidades, das OS que obtiveram indicação de ACEITO pelo FISCAL REQUISITANTE Será considerado como VOLUME MENSAL DE GLOSAS, o total de MAT referentes ao cálculo do somatório das glosas previstas nos três INS em percentuais(%) O VOLUME MENSAL DE PAGAMENTO é a quantidade de MAT, em unidades líquidas a ser considerada para o pagamento e emissão da Nota Fiscal Para aferir o VOLUME MENSAL DE PAGAMENTO sua fórmula de cálculo será a seguinte: VMP=VM-VMG Onde: VMP=Volume Mensal de Pagamento VM=Volume Mensal VMG= Volume Mensal de Glosas 18

19 O VALOR DE PAGAMENTO é o valor em moeda nacional corrente, que fará jus à CONTRATADA, pela quantidade de MAT líquida acumulada no mês a ser considerada para o pagamento e emissão da Nota Fiscal Para aferir o VALOR DE PAGAMENTO sua fórmula de cálculo será a seguinte: VP =VMP X VALOR CONTRATADO DO MAT Onde: VP= Valor de Pagamento VMP=Volume Mensal de Pagamento Para fins de cálculos serão considerados até dois dígitos após a vírgula decimal O pagamento será efetuado mensalmente, de acordo com valor do serviço contratado, comprovados através relatórios mensais por meio do seguinte fluxo: A CONTRATADA entregará ao GESTOR DO CONTRATO, em até 5 (cinco) dias úteis no início de cada mês, um RELATÓRIO PARA PAGAMENTO numerado, contendo as seguintes informações: o total de Ordens de Serviço concluídas; o total de Ordens de Serviço de Garantia concluídas; o total de VERIFICAÇÃO DA QUALIDADE com a indicação de ACEITO ; o total de VERIFICAÇÃO DA QUALIDADE com a indicação de NÃO ACEITO ; o total de Ordens de Serviço concluídas fora do prazo; o total de Ordens de Serviço de Garantia concluídas fora do prazo; a quantidade total de MAT faturadas; uma lista contendo o Número, a Área de Atividade a e quantidade de MAT de cada Ordem de Serviço concluída Poderá ser solicitado à CONTRATADA que novas informações referentes à execução dos serviços 19

20 sejam incluídas no RELATÓRIO PARA PAGAMENTO, desde que a CONTRATADA seja previamente informada por ofício até o dia 20 de cada mês O GESTOR DO CONTRATO homologará o RELATÓRIO PARA PAGAMENTO- Anexo F do Termo de Referência, registrando as glosas, as penalidades pertinentes, a quantidade de MAT aferida e o valor de pagamento em moeda corrente devolvendo-o por ofício em até 7 (sete) dias úteis, da data de recebimento, à CONTRATADA e solicitando a emissão da NOTA FISCAL A CONTRATADA terá prazo máximo de 3 (três) dias úteis, do recebimento do ofício, para apresentar defesa, caso não concorde com algum termo no ofício, que será analisado pela Área Administrativa em até 7(sete) dias úteis, da data de recebimento A não apresentação da defesa, por parte da CONTRATADA, em relação ao RELATÓRIO PARA PAGAMENTO, encaminhado pelo Inep, dentro do prazo estipulado de 3 (três) dias úteis, implicará na plena aceitação dos termos, pela CONTRATADA A CONTRATADA terá prazo máximo de 3 (três) dias úteis, do recebimento do ofício, para emitir a NOTA FISCAL A efetivação do pagamento será mediante a apresentação das Notas Fiscais/Faturas correspondentes, acompanhadas do relatório citado no subitem, devidamente aceitas e atestadas pelo GESTOR DO CONTRATO, em conformidade com o discriminado no TERMO DE REFERÊNCIA Deverá utilizar a unidade denominada como MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT para o dimensionamento do esforço de execução dos serviços, considerando o FATOR DE PONDERAÇÃO- FP subitem 3.1 do Termo de Referência, o FATOR DE CONHECIMENTO INTERNO E MATURIDADE- FACIM subitem 3.2 do Termo de Referência e o resultado obtido conforme qualidade exigida para cada uma das atividades ou artefatos entregues conforme os INDICADORES DE NÍVEIS DE SERVIÇOS subitem 6.4 do Termo de Referência Para a realização do pagamento, a CONTRATADA deverá atender às exigências do art. 36 da Instrução Normativa SLTI nº 2/2008, além de fazer constar da nota fiscal/fatura emitida, sem rasura, em letra legível, o nome do banco, o número da agência e da respectiva conta bancária. O pagamento será realizado em moeda corrente, mediante emissão de ordem bancária para crédito em conta da licitante vencedora, em até 10 dias após o aceite da nota fiscal/fatura. 20

21 O faturamento deverá ser mensal, mediante apresentação de nota de cobrança consolidada, determinando o total de MAT, aprovado pelo CONTRATANTE no RELATÓRIO PARA PAGAMENTO- Anexo F do Termo de Referência, e já descontadas as glosas aplicadas em função do não atendimento dos indicadores de níveis de serviços previstos no Anexo e Termo de Referência, os exigidos contratualmente e os descontos previstos, calculados conforme subitem No caso de discordância das glosas aplicadas pelo GESTOR DO CONTRATO, por não atendimento aos níveis de serviços conforme subitem 6.4 do Termo de Referência, a CONTRATADA deverá apresentar o recurso administrativo e emitir a NOTA FISCAL conforme a totalização estipulada no RELATÓRIO PARA PAGAMENTO - Anexo F do Termo de Referência Se a decisão da Administração for favorável ao recurso da CONTRATADA a mesma emitirá a NOTA FISCAL de cobrança adicional para que seja efetuado o pagamento referente ao custo glosado A NOTA FISCAL de cobrança adicional emitida pela CONTRATADA deverá ser atestada pelo GESTOR DO CONTRATO e encaminhada para a área financeira efetuar o pagamento, acompanhada do RELATÓRIO PARA PAGAMENTO- Anexo F do Termo de Referência, o recurso apresentado pela CONTRATADA, e um memorando com o parecer final do GESTOR DO CONTRATO O RELATÓRIO PARA PAGAMENTO- Anexo F do Termo de Referência deverá especificar o custo aprovado para cada ORDEM DE SERVIÇO e o realmente autorizado, devidamente preenchido e assinado pelo GESTOR DO CONTRATO Em quaisquer casos de aplicação de glosas, deverão ser anexados os documentos e relatórios comprobatórios do não atendimento dos resultados ou níveis de qualidade exigidos As glosas previstas para não atendimento dos INDICADORES DE NÍVEIS DE SERVIÇOS, definidos no Anexo E do Termo de Referência, serão aplicadas pelo GESTOR DO CONTRATO, independentemente das demais penalidades previstas contratualmente O pagamento será realizado através de ordem Bancária, ao Banco e em conta e agência bancária a ser especificada pela CONTRATADA Respeitadas as condições previstas nos parágrafos precedentes deste Contrato, em caso de atraso de pagamento, motivado pelo INEP, o valor devido deverá ser acrescido de atualização financeira, e sua apuração se fará desde a data de seu vencimento até a data do efetivo pagamento, em que os juros de mora serão calculados 21

22 à taxa de 0,5% (meio por cento) ao mês, ou 6% (seis por cento) ao ano, mediante aplicação das seguintes formulas: I = (TX /100) 365 EM = I x N x VP, onde: I = Índice de atualização financeira; TX = Percentual da taxa de juros de mora anual; EM = Encargos moratórios; N = Número de dias entre a data prevista para o pagamento e a do efetivo pagamento; VP = Valor da parcela em atraso O Contrato se adequará de pronto às condições que vierem ser estabelecidas pelo Poder Executivo ou Legislativo A irregularidade Fiscal da CONTRATADA ensejará a suspensão do pagamento, limitada a 30 (trinta) dias a contar do recebimento da notificação pela CONTRATADA, após o que, em não havendo regularização, o contrato poderá ser rescindido de pleno direito 15.6 O INEP não acatará a negociação de duplicatas com bancos ou outras instituições financeiras Em cumprimento ao estabelecido na legislação em vigor, a Coordenação-Geral de Orçamento, Finanças e Contabilidade do INEP reterá na fonte os tributos pertinentes às áreas federal, estadual, distrital ou municipal, e previdenciários que incidirem sobre os pagamentos que efetuar a pessoa jurídica, conforme o caso Caso a empresa seja optante pelo Regime Especial Unificado de Arrecadação de Tributos e Contribuições devidos pelas Microempresas e Empresas de Pequeno SIMPLES NACIONAL, deverá apresentar, junto à nota fiscal eletrônica, declaração na forma do Anexo IV da Instrução Normativa RFB nº 1.234, de 11 de janeiro de 2012, a fim de evitar a retenção na fonte dos tributos e contribuições federais Caso a empresa seja uma instituição de educação e de assistência social, sem fins lucrativos, a que se refere o art. 12 da Lei nº 9.532, de 10 de dezembro de 1997, deverá apresentar, a cada pagamento, declaração na forma do Anexo II da Instrução Normativa RFB n 1.234, de 11 de janeiro de 2012, a fim de evitar a retenção na fonte dos tributos e contribuições federais Caso a empresa seja uma instituição de caráter filantrópico, recreativo, cultural, científico ou associação civil, a que se refere o art. 15 da Lei nº 9.532, de 1997, deverá apresentar, a cada pagamento, declaração na forma do Anexo III da Instrução Normativa RFB nº 1.234, de 11 de janeiro 22

23 de 2012, a fim de evitar a retenção na fonte dos tributos e contribuições federais Poderá ser deduzida do valor da Nota Fiscal/Fatura, multa imposta pelo INEP, se for o caso Antes de efetuar qualquer pagamento será verificada a regularidade da empresa contratada junto ao Sistema Unificado de Cadastro de Fornecedores SICAF e ao CADIN, mediante consulta on line, cujos documentos serão anexados ao processo de pagamento, para comprovação da regularidade das certidões: Certificado de Regularidade da Previdência, Certificado de Regularidade do FGTS, Certificado de Regularidade quanto à Dívida Ativa da União e Certificado de Regularidade de Débitos de Tributos e Contribuições Federais, Estaduais ou Municipais, bem como registro no CADIN. Caso alguma certidão estiver vencida, a Contratada terá o prazo de 5 (cinco) dias úteis para providenciar a regularização. 16 DAS SANÇÕES ADMINISTRATIVAS 16.1 A CONTRATADA ficará sujeita, com fundamento nos artigos 86 e 87 da Lei n /1993, no caso de atraso injustificado, assim considerado pela Administração, de execução parcial ou inexecução da obrigação, sem prejuízo das responsabilidades civil e criminal, assegurada prévia e ampla defesa, às seguintes penalidades: Advertência: Colaborador da CONTRATADA, transitar internamente nas instalações do Inep sem estar devidamente identificado com o respectivo crachá; Colaborador da CONTRATADA, tratar de maneira agressiva, sem cordialidade e desrespeitosa os servidores e demais prestadores de serviços do Inep; Não responder às notificações no prazo determinado, conforme subitem ; Não apresentar documentação exigida, no prazo requerido, tanto da CONTRATADA como dos profissionais, para fazer cumprir os trâmites administrativos do contrato Multa de: % (dois por cento) sobre o VALOR DE PAGAMENTO, no caso de acumular 3 (três) advertências durante a execução do contrato; 23

24 % (dois por cento) sobre o VALOR DE PAGAMENTO, no caso de permitir que profissional sem a qualificação exigida execute os serviços contratados; % (cinco por cento) sobre o VALOR DE PAGAMENTO, no caso de agir de maneira ou com recursos antiéticos dolosamente, buscando obter vantagens administrativas e/ou financeiras na execução do contrato; % (cinco por cento) sobre o VALOR DE PAGAMENTO, no caso de obter valor superior ao VALOR MÁXIMO TOLERÁVEL, conforme subitem do Termo de Referência, em quaisquer INDICADORES DE NÍVEIS DE SERVIÇO, sem prejuízo das GLOSAS previstas; % (cinco por cento) sobre o VALOR DE PAGAMENTO, no caso de atingir a FAIXA MÁXIMA TOLERÁVEL, conforme subitem do Termo de Referência, em mais de 1(um) INDICADOR DE NÍVEIS DE SERVIÇO, sem prejuízo das GLOSAS previstas; % (dois por cento) sobre o valor contratado, no caso de inobservância ao estabelecido no TERMO DE COMPROMISSO; ,2% (zero vírgula dois por cento) por dia de atraso sobre o VALOR DE PAGAMENTO, no caso de descumprimento das obrigações contratuais assumidas, contando a partir de encerrado o prazo de resposta conforme subitem , até o 30º (trigésimo) dia, sem prejuízo das demais penalidades; ,4% (zero vírgula quatro por cento) por dia de atraso sobre o VALOR DE PAGAMENTO, no de descumprimento das obrigações contratuais assumidas após o 30º (trigésimo) dia, limitada ao percentual de 10% (dez por cento), sem prejuízo das demais penalidades Será caracterizada a INEXECUÇÃO TOTAL DO CONTRATO quando, no período de um ano, durante a execução contratual, a CONTRATADA acumular 4 (quatro) MULTAS, sujeitando-a ainda à: Multa de 10% (dez por cento) sobre o valor contratado; Suspensão temporária de participação em licitação e impedimento de contratar com a Administração, por prazo não superior a 2 (dois) anos. 24

25 Declaração de inidoneidade para licitar ou contratar com a Administração Pública enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação perante a própria autoridade que aplicou a penalidade, que será concedida sempre que o contratado ressarcir a Administração pelos prejuízos resultantes e após decorrido o prazo da sanção aplicada com base no inciso anterior A CONTRATADA deverá responder às notificações previstas em, no máximo, 48 (quarenta e oito) horas úteis A contagem das advertências será ZERADA a cada acumulo de 3 (três) advertências procedendo para aplicação de multa conforme subitem Mensalmente será verificado se houve alguma incidência da CONTRATADA nos referidos itens de SANÇÕES E PENALIDADES Será aplica uma única multa sobre o VALOR DE PAGAMENTO, com a soma dos percentuais para cada ocorrência correspondente ao mês verificado Os primeiros noventa dias após a emissão da primeira OS serão considerados como período de adaptação e ajustes, no qual não incidirá MULTA ou SANÇÃO, prevalecendo os demais elementos de faturamento. Nesse período, as multas ou sanções serão calculados para fins de histórico, porém não incidirão penalidades No período de adaptação, se houverem OS entregues fora do prazo estipulado para execução, ou caso a contratada se recuse a atender alguma OS, o período de adaptação será interrompido passando a incidir as penalidades previstas no Termo de Referência Em se tratando de renovação do contrato não caberá o período de adaptação e ajustes, incidindo MULTAS e SANÇÕES previstos a partir da renovação contratual As glosas previstas no subitem 6.4 do Termo de Referência não serão consideradas como SANÇÕES E PENALIDADES para a execução contratual, sendo passíveis de aplicação a partir do primeiro mês de prestação. 25

26 17 DA CONTRATAÇÃO 17.1 Após a homologação da licitação o adjudicatário terá o prazo de 10 (dez) dias, contados a partir da data de convocação pelo Inep, podendo ser prorrogado uma vez, por igual período, quando solicitado pela parte e desde que ocorra motivo justificado e aceito pelo Órgão, na forma da minuta apresentada no Anexo III do Edital, sob pena de decair o direito à contratação Na assinatura do contrato, será exigida a comprovação das condições de habilitação consignadas no edital, as quais deverão ser mantidas pelo licitante durante a vigência do contrato O vencedor da licitação que não fizer a comprovação referida no subitem anterior ou quando, injustificadamente, recusar-se a assinar o contrato, poderá ser convocado outro licitante, desde que respeitada a ordem de classificação, para, após comprovados os requisitos habilitatórios e feita a negociação, assinar o contrato, sem prejuízos das multas previstas em edital e no contrato e das demais cominações legais Somente será considerada habilitada a licitante que houver preenchido os requisitos de habilitação na data da primeira sessão Os concorrentes remanescentes convocados na forma do subitem anterior se obrigam a atender a convocação e a assinar o Contrato/retirar a Nota de Empenho, no prazo fixado pelo INEP, ressalvados os casos de vencimento das respectivas propostas, sujeitando-se às penalidades cabíveis no caso de recusa ou de não atendimento das condições de habilitação A licitante vencedora deverá comprovar a qualificação profissional para a prestação dos serviços que trata o item 10 do TERMO DE REFERÊNCIA, Anexo I deste Edital A licitante vencedora deverá prestar garantia contratual, nos termos do art. 56 da Lei nº 8.666/93,. Como garantia da execução plena do seu objeto e fiel cumprimento do presente Contrato, a CONTRATADA prestará garantia correspondente a 5% (cinco por cento) do valor global do Contrato, na forma do art. 56, 1, da Lei n 8.666/93 no ato de assinatura do Contrato 17.6 O valor da garantia permanecerá integral até o término da vigência do contrato. A reposição de seu valor, quando for o caso, será feita em até 72 (setenta e duas) horas, contadas da data de recebimento da notificação do Inep O valor da garantia reverterá, integralmente, em favor do Inep, ou pelo saldo que apresentar, no caso de rescisão contratual por culpa da CONTRATADA, sem prejuízo das perdas e danos porventura verificados O Inep poderá utilizar o valor da garantia prestada para descontar os valores referentes a eventuais multas aplicadas à CONTRATADA, bem como nos casos decorrentes de inadimplemento contratual, e de indenização por danos causados ao Patrimônio da União ou de terceiros, ocorridos nas suas dependências A garantia prestada pela CONTRATADA será liberada ou restituída após o término da vigência ou rescisão do Contrato, desde que não haja pendências. 26

27 17.10 A vigência do contrato será de 12 (doze) meses, prorrogáveis por iguais e sucessivos períodos, limitada a sessenta meses, conforme previsto no inciso II do art. 57, da Lei nº 8.666/ A Contratada responderá civil, penal e administrativamente por qualquer prejuízo que venha a causar ao INEP, decorrente da execução imperfeita ou da inexecução parcial ou total do contrato. 18 DA ESTIMATIVA DE CUSTOS E DA DOTAÇÃO ORÇAMENTÁRIA 18.1 De acordo com pesquisas de preços efetuadas no mercado, o custo médio total da contratação foi estimado em R$ ,00 (sete milhões e oito mil reais), conforme consta no detalhamento do item 7 do Termo de Referência anexo I deste Edital O recurso orçamentário para atender a despesa com a manutenção está previsto no Orçamento Geral do INEP Ação 20RH PTRES DAS DISPOSIÇÕES GERAIS 19.1 A autoridade competente para a aprovação do procedimento licitatório somente poderá revogá-lo em face de razões de interesse público decorrentes de fato superveniente devidamente comprovado, pertinente e suficiente para justificar tal conduta, devendo anulá-lo por ilegalidade, de ofício ou por provocação, mediante ato escrito e devidamente fundamentado, nos termos do art. 18 do Decreto nº 3.555/00 e art. 29 do Decreto nº 5.450/05, c/c art. 49 da Lei nº 8.666/ Havendo indícios de conluio entre os licitantes ou de qualquer outro ato de má-fé, o INEP comunicará os fatos verificados à Secretaria de Direito Econômico do Ministério da Justiça e ao Ministério Público Federal, para as providências devidas É faculdade do Pregoeiro ou da Autoridade Superior, em qualquer etapa da licitação, a promoção de diligência destinada a esclarecer ou complementar a instrução do processo Fica assegurado ao INEP, o direito de no interesse da Administração, anular ou revogar, a qualquer tempo, no todo ou em parte, a presente licitação, dando ciência aos participantes, na forma da legislação vigente Os licitantes assumem todos os custos de preparação e apresentação de suas propostas e o INEP não será, em nenhum caso, responsável por esses custos, independentemente da condução ou do resultado do processo licitatório Os serviços e bens deverão ser entregues com todas as despesas por conta exclusiva da contratada e quaisquer ações civis/penais/trabalhistas ou de qualquer natureza que decorram de ato ou omissão da prestação de seus serviços serão de exclusiva responsabilidade da empresa contratada, bem assim como todas as despesas de entrega dos referidos bens no endereço indicado da contratada Os proponentes são responsáveis pela fidelidade e legitimidade das informações e dos documentos apresentados em qualquer etapa da licitação. 27

28 19.8 As normas que disciplinam este Pregão Eletrônico serão sempre interpretadas em favor da ampliação da disputa entre os interessados, sem comprometimento da segurança da futura prestação dos serviços Este Edital será fornecido a qualquer interessado, através do sítio A homologação do resultado desta licitação, não implicará em direito à contratação do objeto licitado, no todo ou em parte Como condição para emissão da Nota de Empenho, será verificada a regularidade do adjudicatário, vencedor da licitação, junto ao SICAF, SIAFI e CADIN Aos casos omissos aplicar-se-ão as demais disposições constantes da Lei nº , de 17 de julho de 2002, dos Decretos nºs , de 8 de agosto de 2000, 3.693, de 20 de dezembro de 2000, 5.450, de 31 de maio de 2005, 3.784, de 6 de abril de 2001, IN-MPOG nº 02 de 30 de abril de 2008, e suas alterações posteriores, IN-MPOG nº 4, de 12 de novembro de 2010, Lei Complementar nº 123/2006, Decreto nº 6.204/2007, Lei nº de 11/09/1990, Decreto nº 7.174/2010 e subsidiariamente a Lei nº 8.666/93 e suas alterações posteriores A DTDIE exercerá a fiscalização da execução do contrato por meio de servidor público habilitado e nomeado As disposições e especificações contidas neste Edital serão parte integrante do contrato, devendo ser observadas e atendidas em sua plenitude, cabendo a aplicação de penalidades no descumprimento de qualquer dos seus itens e no que couber a IN-MPOG nº 02, de 30 de abril de 2008, e suas alterações posteriores, e IN-MPOG nº 4, de 12 de novembro de A existência de Fiscalização não diminui ou atenua a responsabilidade da Contratada pela execução de qualquer serviço A Fiscalização deverá recusar qualquer serviço executado fora das condições contratuais ou do bom padrão de acabamento Fica eleito o Foro da Justiça Federal, Seção Judiciária do Distrito Federal - DF, para solucionar quaisquer litígios oriundos desta licitação. Brasília, de novembro de LUIZ AUGUSTO LUCINDA Coordenador Geral de Recursos Logísticos, Aquisições e Convênios. 28

29 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS Quadra 701, Bloco M, Asa Sul, Ed. Sede do Inep, 2º Andar. CEP: CNPJ / (61) / 3240 / 3235 Fax PREGÃO ELETRÔNICO Nº XX/2012 DTDIE/ INEP ANEXO I TERMO DE REFERÊNCIA 29

30 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS TERMO DE REFERÊNCIA 1 DEFINIÇÃO DO OBJETO O objeto desta contratação é a prestação de serviços na área de Tecnologia da Informação para ASSESSORIA TECNOLÓGICA EM SISTEMAS DE INFORMAÇÃO visando prover a Diretoria de Tecnologia e Disseminação de Informações Educacionais (DTDIE) de capacidade organizacional para operacionalizar os serviços de TI e atender às necessidades tecnológicas do Inep que compreendem: ANÁLISE DE ARQUITETURA DE SISTEMAS e ANÁLISE DE NEGÓCIO PARA SISTEMAS, mediante ordens de serviço dimensionadas pela MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT, limitada ao quantitativo máximo de até (MAT) anuais, sem garantia de consumo mínimo. 2 FUNDAMENTAÇÃO DA CONTRATAÇÃO 2.1 DEMANDA Contratação de empresa objetivando a prestação de serviços de assessoria tecnológica de sistemas de informação, que possua capacitação técnica necessária para atender em plenitude as especificações constantes neste TERMO DE REFERÊNCIA e seus anexos, para execução das atividades demandadas, mediante o menor valor global anual para até MAT (MÉTRICA PARA ASSESSORIA TECNOLÓGICA) em item único, sem garantia de consumo mínimo Os serviços de assessoria tecnológica de sistemas de informação e processos a serem prestados pela CONTRATADA são de apoio relativo às seguintes áreas de atuação: Análise de Arquitetura de Sistemas: Prestação de serviços de suporte às atividades de arquitetura de sistemas. Tais atividades envolvem a formulação de proposta para ambiente de desenvolvimento, processos de configuração, mudança, elaboração de padrões tecnológicos a serem utilizados e arquitetura de referência; modelagem e implementação de soluções integradoras. Análise de Negócio para Sistemas: Prestação de serviços de suporte às atividades de análise de negócio, envolvendo o domínio e a aplicação de técnicas utilizadas para identificar e relacionar partes interessadas e documentar suas necessidades, requisitos e regras, no intuito de compreender a estrutura, as políticas e operações das diversas áreas de negócio do Inep, viabilizando o alcance das metas organizacionais a partir da adoção de soluções de TI Para dimensionar os serviços e por não existir métrica usual no mercado para os serviços que se pretende contratar, a DTDIE desenvolveu uma forma própria para aferição desses serviços, a Métrica para Assessoria Tecnológica- MAT. Por se tratar de uma métrica nova, não há informações consistentes ou bases históricas para estimar uma quantidade exata de consumo anual. 30

31 2.1.4 Por se tratar de serviços que exigem profissionais altamente qualificados e experientes foi adotado como parâmetro para a métrica a Hora do Profissional Sênior. O valor para a MAT será parametrizado pela seguinte fórmula: 1 MAT= 1 hora de trabalho de um profissional Analista de Sistemas Sênior. TABELA 1 Expectativa de Consumo de MAT por Área de Atividade Área de Atividade Quantidade Estimada Análise de Arquitetura de Sistemas Análise de Negócio para Sistemas TOTAL A Tabela acima apresenta a expectativa de esforço, em MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT, para cada ano de execução contratual. Os itens da Tabela poderão sofrer alteração de quantitativos, no decorrer da execução, em função das mudanças de estratégias, priorização das tarefas, inclusão e exclusão de demandas, desde que não superem a estimativa total contratada, o que somente poderá ocorrer mediante TERMO ADITIVO e dentro dos percentuais legais previstos conforme Lei nº 8.666/93, art.65º Por não haver bases históricas que permitissem estimativas mais concretas, o quantitativo de MAT para área de atividade não é exaustivo. Sendo considerado o volume total como fonte única de MAT para todas as áreas de atividades, conforme as necessidades de demanda As demandas serão controladas por ORDENS DE SERVIÇO- OS, emitidas e autorizadas conforme necessidade da Diretoria de Tecnologia e Disseminação de Informações Educacionais (DTDIE), não tendo características uniformes ao longo do período, sendo quitadas apenas as que forem devidamente concluídas pela empresa prestadora Optou-se pela utilização da modalidade PREGÃO para a presente contratação, por se tratar serviços de tecnologia da informação considerados comuns, ou seja, aqueles que possuam padrões de desempenho e de qualidade objetivamente definidos pelo edital, com base em especificações usuais no mercado, conforme Lei nº /2002, art. 1º; Acórdão nº 2.471/2008-TCU- Plenário item MOTIVAÇÃO O Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira (Inep) é uma autarquia federal vinculada ao Ministério da Educação (MEC), cuja missão é promover estudos, pesquisas e avaliações sobre o Sistema Educacional Brasileiro com o objetivo de subsidiar a formulação e implementação de políticas públicas para a área educacional a partir de parâmetros de qualidade e equidade, bem como produzir informações claras e confiáveis aos gestores, pesquisadores, educadores e público em geral. Para gerar seus dados e estudos educacionais o Inep realiza levantamentos estatísticos e avaliativos em todos os níveis e modalidades de ensino: Censo Escolar: levantamento de informações estatístico-educacionais de âmbito nacional, realizado 31

32 anualmente; Censo Superior: coleta, anualmente, uma série de dados do ensino superior no País, incluindo cursos de graduação, presenciais e à distância. Avaliação dos Cursos de Graduação: é um procedimento utilizado pelo MEC para o reconhecimento ou renovação de reconhecimento dos cursos de graduação representando uma medida necessária para a emissão de diplomas. Avaliação Institucional: compreende a análise dos dados e informações prestados pelas Instituições de Ensino Superior (IES) no Formulário Eletrônico e a verificação, in loco, da realidade institucional, dos seus cursos de graduação e de pós-graduação, da pesquisa e da extensão. Sistema Nacional de Avaliação da Educação Superior: Criado pela Lei n , de 14 de abril de 2004, o Sinaes é o novo instrumento de avaliação superior do MEC/Inep. Ele é formado por três componentes principais: a avaliação das instituições, dos cursos e do desempenho dos estudantes. Exame Nacional do Ensino Médio (Enem): exame de saída facultativo aos que já concluíram e aos concluintes do ensino médio, aplicado pela primeira vez em Exame Nacional Para Certificação de Competências (Encceja): é uma proposta do Ministério da Educação de construir uma referência de avaliação nacional para jovens e adultos que não puderam concluir os estudos na idade própria. Sistema Nacional de Avaliação da Educação Básica (Saeb): pesquisa por amostragem, do ensino fundamental e médio, realizada a cada dois anos. A Diretoria de Tecnologia e Disseminação de Informações Educacionais (DTDIE) organiza e sistematiza dados e informações relacionados a áreas responsáveis pelos processos de coleta, de estudo e de avaliação educacional. A diretoria é responsável por planejar, propor e desenvolver mecanismos, instrumentos e produtos de disseminação e documentação de informações educacionais do Inep, oferecendo suporte à divulgação de resultados e produtos dos sistemas de avaliação e de indicadores e estatísticas educacionais, em articulação com as outras diretorias do órgão. A DTDIE também tem a função de administrar os recursos de informação, informática e telecomunicação da Instituição. A DTDIE, para atender as necessidades das diretorias fins, possui infraestrutura de equipamentos e comunicação de TI bem como desenvolve e mantém sistemas. Para o desenvolvimento e manutenção dos sistemas a DTDIE conta com a seguinte organização: Fábrica de Software; Divisão de Projetos; Divisão de Métricas; Equipe de Testes; Divisão de Arquitetura de Sistemas e Qualidade. A DTDIE adotou a modalidade de Fábrica de Software para os serviços de desenvolvimento e manutenção de sistemas, dimensionados pela técnica de Análise de Ponto de Função- APF, e atualmente possui contrato com empresa terceirizada para os Serviços de Suporte de Infraestrutura que compreendem: suporte de atendimento ao usuário, suporte tecnológico ao ambiente computacional de infraestrutura de redes, seus meios de comunicação, sistemas funcionais e processos de execução, dimensionada pela Unidade de Serviço Técnico- UST. Porém, as atividades de apoio, pretendidas para esta contratação: Análise de Arquitetura de Sistemas e 32

33 Análise de Negócio para Sistemas, apesar das suas imprescindibilidades no processo de Engenharia de Software, não são passíveis de execução pela Fábrica de Software ou pelos Serviços de Infraestrutura por se tratarem de objetos diferentes à natureza dos serviços pretendidos. O quadro funcional do Inep, responsável pela administração, manutenção, monitoração e suporte dessas atividades, é bem reduzido, e, mesmo que preparado tecnicamente para assumir em plenitude as atividades necessárias, é insuficiente para atender e manter todos os serviços existentes, além de não poder dedicar à evolução do ferramental e gestão dos serviços, caso tivessem que executar tais atividades pretendidas neste TERMO DE REFERÊNCIA. Dessa forma faz-se necessária a contratação de uma empresa que forneça os recursos necessários para atuar nos serviços em que a fábrica de software não oferece suporte, bem como no apoio às atividades das áreas elencadas, buscando manter a Diretoria de Tecnologia e Disseminação de Informações Educacionais com foco nas estratégias, metas e objetivos permitindo a melhoria dos processos, produtos e serviços prestados pela DTDIE, em atendimento às necessidades do Inep. O momento atual da administração pública necessita de um maior controle da governança de TI, necessidade essa exaustivamente relatada na jurisprudência do Tribunal de Contas da União. A Instrução Normativa SLTI/MP Nº 4/2010, publicada pela Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento, Orçamento e Gestão, busca disciplinar os processos de contratação de serviços de TI e de gestão dos respectivos contratos. Conforme tal norma deve-se contratar bens e serviços a partir da adoção de uma métrica que permita a vinculação dos pagamentos ao tamanho dos serviços solicitados e entregues. 2.3 RESULTADOS A SEREM ALCANÇADOS O exercício de atividades de TI no âmbito do SISP (Sistema de Administração de Recursos de Informação e Informática) deve contemplar basicamente a gestão, sendo recomendável que as atividades de execução se façam na forma de contratação de serviços, excetuados os casos em que condições especiais exijam execução por servidores públicos. O Inep espera obter, com esta contratação, o total alinhamento com as orientações emanadas pelos órgãos reguladores e com a legislação vigente, no que diz respeito à substituição dos contratos de postos de trabalho e homens/hora, de difícil aferição dos resultados. O processo de contratação proposto atende às recomendações legais, proporcionando ampla disputa licitatória. Na essência desse processo está o conceito de pagamento por produtos/serviços efetivamente fornecidos/executados. O modelo estabelece padrões adequados de resultados com vistas ao ganho de escala produtiva, a facilidade de custeamento e orçamentação e a ampla competitividade do mercado, vinculados às práticas de padronização de serviços e definição de resultados. 33

34 Sua sustentabilidade foi atrelada ao princípio da eficiência, tendo em sua modelagem de demanda e especificação de serviços à exigência de definição técnico administrativa pelos servidores, e a execução operacional por parte da CONTRATADA, combinada por processos de trabalho previamente formatados e documentados, além de indicadores de qualidade dos produtos/serviços. O modelo permitirá a independência o Inep em caso de mudanças futuras da empresa contratada, pelo simples fato de todos os processos estarem devidamente documentados. A quantificação do volume e o nível de serviço definido assegurarão ao CONTRATANTE a posse efetiva de todos os procedimentos e informações necessárias para a continuidade por outra empresa, principalmente quanto ao conhecimento do negócio institucional envolvido em cada processo. Resumindo, a contratação proposta é viável para a organização, por atender os principais quesitos de contratação e com base nos seguintes princípios: Eficácia: As ordens de serviços prevêem o prazo para execução e estão baseadas em resultados e níveis de qualidade definidos. Eficiência: Os prazos previstos serão definidos de acordo com a experiência do corpo técnico e a necessidade da organização, sendo factíveis e realizáveis se a CONTRATADA estiver provida de recursos profissionais especializados, capacitados e experientes na execução das atribuições demandadas. Como requisitos para obtenção desse objetivo, para tarefas que atendam a serviços considerados críticos pela DTDIE, serão exigidas certificações específicas que comprovem o conhecimento dos recursos envolvidos. Isso proporcionará a remuneração pelo custo real e de acordo com o resultado. Economicidade: A definição dos resultados, vinculados aos níveis de serviços exigidos para cada produto demandado, proporcionará ao CONTRATANTE resultados efetivos por custos justos, já que as especificações prévias da maioria das tarefas em fase licitatória dará às concorrentes igualdade de condições para provisionar o custo real da contratação. Isonomia: A definição prévia da totalidade dos serviços previstos e a expectativa mínima de execução proporcionarão a todos os concorrentes conhecimentos prévios dos serviços exigidos, dando visibilidade ao processo e permitindo a livre concorrência de mercado. Padronização: Os modelos de demandas e os resultados exigidos apoiados em documentações técnicas, registros, processos de trabalho e procedimentos de execução proporcionam um padrão de produtividade, independentemente dos adotados para efetivação de melhores práticas. Quando um ou mais destes padrões de governança forem adotados, bastará o reajustamento dos modelos utilizados para adequação às novas exigências, mantendo o conhecimento do negócio e as metodologias de produção a cargo do CONTRATANTE. 34

35 Parcelamento: A contratação prevê como ganhadora a concorrente que fornecer menor preço global para o total de Métrica para Assessoria Tecnológica- MAT previstas, mas conceitua que seu pagamento será efetuado de acordo com a entrega de cada produto, que deverá ser contabilizada para cada atividade prevista. Portanto, a execução será parcelada em Métrica para Assessoria Tecnológica- MAT devidamente justificados e mensurados pela equipe técnica interna. Quantitativo: A formulação do quantitativo prevê a execução nos próximos 12 meses, já que os custeios das atividades de Assessoria Tecnológica em Sistemas de Informação e Processos realizáveis no Inep encontram-se estimados. Os valores estimados foram fixados com base na técnica, experiência interna e capacitação histórica da equipe da DTDIE. Caracterização: O modelo de prestação de serviços prevê que a CONTRATADA seja integralmente responsável pela gestão de seu pessoal em todos os aspectos, sendo vedado à equipe do Inep, formal ou informalmente, qualquer tipo de ingerência ou influência sobre a administração da mesma, ou comando direto sobre seus empregados, fixando toda negociação na pessoa do PREPOSTO da CONTRATADA ou seu substituto. Produtividade: A prestação de serviços com base em linha de produção em série com prazos para entrega, apoiada em padronização documentada de serviços, modelos de melhores práticas para a área de TI, condicionando o pagamento aos resultados obtidos para cada serviço demandado proporcionará ganhos de produtividade nas atividades de Assessoria Tecnológica em Sistemas de Informação e Processos do Inep. 2.4 JUSTIFICATIVA DA SOLUÇÃO ESCOLHIDA A proposição de uma unidade de referência, unida às especificações predeterminadas das tarefas e atividades a serem executadas, com a definição dos resultados esperados dentro do padrão de qualidade acordado e a estipulação dos fatores de glosas diretamente vinculadas a cada tarefa/resultado, proporcionará ao Inep melhor qualidade dos seus serviços. Na razão custo X benefício, permitirá ao Inep estimar o custo real de cada atividade demandada, tomando por base o tempo necessário para execução e o tipo de especialista necessário para realização de cada procedimento, vinculando o resultado à qualidade desejada. Ao contrário dos modelos anteriores, que eram baseados na alocação de profissionais remunerados na forma homem/hora, o modelo proposto permite o custeio mais próximo da realidade comercial. As demandas previamente definidas em ATIVIDADES solicitadas por meio de ORDENS DE SERVIÇOS- OS, dentro dos padrões de qualidade exigidos pelo modelo de produção, exigirão dos técnicos do Inep a definição das etapas a serem executadas, dos recursos exigidos e dos objetivos para execução. Não implica nenhuma obrigação de conhecimento técnico além das que qualificaram a equipe para exercício das funções no 35

36 Inep. Além desse conhecimento técnico específico, a única modelagem que deverão exercer com maior ênfase é a prevista pelo Decreto Lei 200/67, de melhor executar as tarefas de planejamento, coordenação, supervisão e controle. O CONTRATANTE disponibilizará, para execução das atividades de assessoria tecnológica, um local de trabalho para a equipe contratada, sob o comando do PREPOSTO, que definirá as funcionalidades e tarefas dos seus recursos técnicos em número suficiente para atender ao mínimo exigido pelo CONTRATANTE sem a influência dos servidores do CONTRATANTE, desde que cumpridas todas as normas técnicas, regras de segurança e boa conduta exigida pela organização, que será repassada para a CONTRATADA no momento da contratação. Dentre os resultados pretendidos para a contratação, é de se destacar os objetivos de negócio da DTDIE, necessários aos serviços e produtos que são fornecidos em atendimento às necessidades do Inep: Apoio para auditar e revisar sistemas em desenvolvimento e em produção, efetuando avaliação de riscos, requisitos de conformidade, qualidade, confiabilidade e segurança de dados e informações; Investigar os sistemas do Inep a fim de fornecer informações sobre sua qualidade em relação ao contexto em que devem operar; Ampliar a capacidade para medir e prospectar tecnologias para suportar os serviços e processos de negócio do Inep; Implantar padrões, metodologias e ferramentas para apoiar a gestão de TI. Muitas atividades fundamentais para sustentação da missão institucional do INEP estão fortemente relacionadas e dependentes dos serviços das áreas de assessoria tecnológica de sistemas de informação, de maneira que a indisponibilidade desses serviços produzirá impacto direto sobre o seu desempenho institucional. 3 DESCRIÇÃO DA SOLUÇÃO DE TI A solução de TI a ser contratada compõe-se de serviços necessários para a assessoria tecnológica dos sistemas e projetos de TI do INEP. Entendam-se como Assessoria Tecnológica atividades, ou demandas, ligadas às áreas de Análise de Arquitetura de Sistemas e Análise de Negócio para Sistemas, com as quais almejamos: Buscar conformidade com os padrões do governo eletrônico para o desenvolvimento de software. Analisar uso de métodos e ferramentas a serem padronizados na organização. Buscar melhoria contínua no processo de desenvolvimento de software. Identificar, documentar e publicar regras de negócio, assim como todo o conhecimento gerado durante o ciclo de vida de cada produto de software, de forma a compor uma base de conhecimentos que possa ser disseminada internamente. Prospectar tecnologias que poderão ser utilizadas na Organização. Planejar projetos, e acompanhar resultados. 36

37 Estudar, detalhar, descrever, documentar e especificar manutenções adaptativas, corretivas e evolutivas de sistemas de informação. Prospectar elaboração e melhorias dos guias e padrões existentes no Inep em conformidade com as boas práticas de mercado. Definir componentes de software, suas propriedades e seus relacionamentos com outros sistemas inerentes ou não ao Inep. Maturar o processo de desenvolvimento e implantação de produtos de sistemas de informação. O Inep possui atualmente um ambiente computacional diversificado, divididos em: estações de trabalho, notebooks, linguagens de desenvolvimento, ferramentas de apoio ao desenvolvimento, ferramentas de apoio à análise, ferramenta de gerenciamento de projetos e contratos, ferramenta de controle de demandas, ferramentas de monitoramento/gestão de Lan e/ou Wan e servidores de rede; conforme QUADRO DE RECURSOS DE TI- Anexo G e RELAÇÃO DE SISTEMAS QUE COMPÕEM O LEGADO DO INEP- Anexo H utilizados pela DTDIE em apoio aos objetivos de negócios do Inep. A integração dos serviços dessas áreas permite a continuidade, qualidade e disponibilidade dos sistemas aplicativos mantidos pelo Inep. A diversidade de produtos, funcionando de maneira integrada e interagindo com soluções providas por outros fabricantes de software, confere alta complexidade ao ambiente, o que requer da equipe técnica um grande esforço no sentido de torná-lo íntegro e, tanto quanto possível, disponível para os usuários internos e externos ao INEP, cujos trabalhos dependem do pleno funcionamento deste ambiente computacional. Por meio dessa contratação, busca-se promover novos serviços para assessoria dos sistemas, procedimentos e análises mais completas de serviços, produtos e necessidades. Esse processo de terceirização de atividades operacionais e técnicas vem se tornando cada vez mais intenso nas organizações, sejam elas de natureza pública ou privada. No caso específico do segmento de tecnologia da informação, o referido processo tem se acelerado nos últimos anos, em decorrência das normas legais, de orientações do TCU e do seu comprovado sucesso. Ele desonera as organizações dos altos custos de operação, sustentação e manutenção do ambiente de tecnologia da informação, especialmente quanto aos esforços diretos e indiretos de manutenção e para aperfeiçoamento de quadro de profissionais especializados nestas atividades. Ainda, possibilitará ao quadro técnico interno dedicarse às principais tarefas definidas pelo DL 200/67, em seu Art. 10, 7º, quando determina que: A execução das atividades da Administração Pública Federal deverá ser amplamente descentralizada, de forma a permitir ao servidor [...] melhor desincumbir-se das tarefas de planejamento, coordenação, supervisão e controle e com o objetivo de impedir o crescimento desmesurado da máquina administrativa, a Administração procurará desobrigar-se da realização material de tarefas executivas, recorrendo, sempre que possível, à execução indireta, mediante contrato, desde que exista, na área, iniciativa privada suficientemente desenvolvida e capacitada a desempenhar os encargos de execução. 37

38 A prestação de serviços para assessoria tecnológica pretendida objetiva, primordialmente, o atendimento aos projetos estratégicos do Inep e às necessidades do suporte técnico aos sistemas desenvolvidos, mantidos, ou em desenvolvimento mediante execução operacional das atividades previstas na contratação. O modelo de contratação mais usual no mercado para esse tipo prestação é o de postos de trabalho, em que os técnicos prestadores são inseridos no quadro e distribuídos entre as áreas conforme suas especialidades, modelo esse, pouco recomendado pelo TCU. Esse, além de oneroso para a organização, visto que cada técnico inserido tem a funcionalidade especificada conforme categoria de atividade é avaliado como pouco produtivo se considerar que o prestador contratado permanecerá boa parte do tempo sem realizar quaisquer serviços diretamente relacionados com sua especialidade, sendo deslocado, na maior parte do exercício, para execução de atividades cujos custos mercadológicos seriam bem inferiores ao realmente pago pelo profissional. Também há de considerar os períodos de férias e licenças em que, mesmo sendo substituídos por outros especialistas, proporcionam resultados pouco produtivos pela falta de conhecimento deste no negócio da Organização e no funcionamento do setor. O novo paradigma de contratações de serviços de TI da Administração Pública Federal tem como base seis pilares: planejamento, parcelamento dos serviços, pagamento por resultados, avaliação da qualidade, controle efetivo da execução contratual e existência de recursos humanos capacitados. No Art. 15, 2 e 3, da IN 04/2010 temos: A aferição de esforço por meio da métrica homens-hora apenas poderá ser utilizada mediante justificativa e sempre vinculada à entrega de produtos de acordo com prazos e qualidade previamente definidos. É vedado contratar por postos de trabalho alocados, salvo os casos justificados mediante a comprovação obrigatória de resultados compatíveis com o posto previamente definido. A IN 02/2008 em seu Art. 11 diz: A contratação de serviços continuados deverá adotar unidade de medida que permita a mensuração dos resultados para o pagamento da contratada, e que elimine a possibilidade de remunerar as empresas com base na quantidade de horas de serviço ou por postos de trabalho. Buscando atender aos ordenamentos jurídicos citados e por não existir nenhuma técnica de medição que possa ser aplicada à contratação pretendida; a DTDIE inova neste processo ao desenvolver um método de medição e pagamento por resultado, denominada de MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT. Foi considerado para sua concepção: cenários dos serviços, características internas de processos ou procedimentos, parque tecnológico, normas e regulamentos institucionais, quantidade de projetos e sistemas mantidos, além de outros. A unidade de referência adotada para sua validação é inicialmente equivalente a 1 h (uma hora) de 38

39 trabalho de assessoria tecnológica executada por um profissional ANALISTA DE SISTEMAS SÊNIOR. O valor da MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT proposto pela licitante deverá ser capaz de cobrir todos os custos necessários à execução dos serviços e entregas dos artefatos, considerando o PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A previsto no subitem 5.10, os critérios que implicarão diretamente para variação da métrica, previstos nos subitens 3.1 e 3.2, os requisitos de qualificação das equipes técnica previstos no subitem e as etapas previstas no modelo de prestação de serviço e metodologia de trabalho descrito no item 5 neste Termo de Referência. Dada a variação na complexidade das atividades existentes para este TERMO DE REFERÊNCIA e também na criticidade de uso do serviço em relação ao funcionamento da mesma com a finalidade principal da organização, fez-se necessário criar outros critérios que implicarão diretamente para variação da métrica e contabilização para os serviços requeridos, que seguem: 3.1 O Fator de Ponderação- FP é a adoção de um valor de referência único buscando facilitar a contabilização dos serviços, exigindo do corpo técnico, FISCAL REQUISITANTE, FISCAL TÉCNICO e do GESTOR DO CONTRATO, a definição do fator de ponderação para a execução de cada atividade. Foram definidos três graus para o fator de ponderação: BAIXO, MÉDIO e ALTO Os graus do FP foram definidos pelo corpo técnico da DTDIE apoiados na perspectiva da necessidade, dificuldade e tempo estimado para execução das atividades propostas. Seguindo estes critérios, determinou-se a quantidade de MAT para cada atividade no Fator de Ponderação para o grau BAIXO. Para os demais graus do FP a definição da quantidade foi balizada pela seguinte tabela de referência: TABELA 2 Tabela de Referência para Quantificação de MAT por Grau de FP Fator de Ponderação BAIXO MÉDIO ALTO Quantidade de MAT Definido pelo Corpo Técnico da DTDIE 2 X ( a quantidade do BAIXO) 3,33 X (a quantidade do BAIXO) O FISCAL REQUISITANTE indicará o FP apoiado pelos critérios: NÍVEL DE COMPLEXIDADE, NÍVEL DE IMPACTO, NÍVEL DE CRITICIDADE que cada atividade necessitar, conforme TABELA PARA FATOR DE PONDERAÇÃO, subitem O NÍVEL DE COMPLEXIDADE está relacionado diretamente com a natureza da atividade e o esforço necessário para a sua execução ou solução de incidente. O nível de complexidade será definido pelo FISCAL REQUISITANTE apoiado na perspectiva da dificuldade para a execução da atividade solicitada. Foram definidos três níveis de complexidades: BAIXO: Atividade que em sua natureza requer um baixo grau de esforço. MÉDIO: Atividade que requer razoável esforço, sendo necessário médio grau de análise para execução e/ou solução de incidentes. ALTO: Atividade que requer grande esforço, sendo necessário alto grau de análise para execução e/ou solução de incidentes. 39

40 3.1.4 O NÍVEL DE IMPACTO está relacionado ao efeito nos processos de negócio do Inep ou da DTDIE, o quanto os serviços serão afetados com falha, necessidade de evolução ou adaptação e qual será o transtorno, interno ou externo, pela não realização da atividade. O nível de impacto será definido pelo FISCAL REQUISITANTE apoiado na perspectiva dos objetivos de negócio, imagem da instituição e quantidade de clientes ou usuários afetados. Foram definidos três níveis de impacto: BAIXO: Contexto em que uma falha ou uma perda de performance não compromete os processos de negócio do Inep ou da DTDIE, com poucos usuários ou clientes e não afeta a imagem da organização ou diretoria. MÉDIO: Contexto em que uma falha ou uma perda de performance pode comprometer os processos de negócio do Inep ou da DTDIE, com poucos usuários ou clientes, podendo afetar a imagem da organização ou diretoria. ALTO: Contexto em que uma falha ou uma perda de performance compromete os processos de negócio do Inep ou da DTDIE, com muitos usuários ou clientes afetando a imagem da organização ou diretoria O NÍVEL DE CRITICIDADE está relacionado ao tempo de execução considerando que atrasos, na execução das atividades ou na entrega dos artefatos, podem afetar um processo de negócio do Inep ou da DTDIE. O nível de criticidade será definido pelo FISCAL REQUISITANTE apoiado na perspectiva dos objetivos de negócio e na velocidade que deverá ser realizada a atividade para cumprir o prazo definido. Foram definidos dois níveis de criticidade: NORMAL: Contexto em que a atividade seguirá velocidade de trabalho normal devendo ser concluída em prazo normal, onde possíveis atrasos não afetarão os processos de negócios da organização ou diretoria. CRÍTICO: Contexto em que a atividade não pode ser adiada devendo ser executada rapidamente e com prazo reduzido para a execução, onde possíveis atrasos afetarão os processos de negócios da organização ou diretoria A TABELA PARA FATOR DE PONDERAÇÃO será utilizada pelo FISCAL REQUISITANTE para auxiliar na definição do grau para o FP. TABELA 3 Tabela para Fator de Ponderação Complexidade Impacto Criticidade Fator de Ponderação B B N B B B C B B M N B B M C M B A N M B A C M M B N B M B C M M M N M M M C M M A N M M A C A 40

41 A B N M A B C M A M N M A M C A A A N A A A C A Legenda: B= BAIXO M= MÉDIO A= ALTO N=NORMAL C=CRÍTICO A indicação de qualquer dos critérios no nível de ALTO, MÉDIO e CRÍTICO deverá ser justificada por escrito pelo FISCAL REQUISITANTE na ORDEM DE SERVIÇO e, após avaliação do FISCAL TÉCNICO e do GESTOR DO CONTRATO, a ORDEM DE SERVIÇO será autorizada, ou não, ter a indicação dos referidos critérios Caso o FISCAL TÉCNICO ou GESTOR DO CONTRATO entenderem não ser procedente alguma indicação dos níveis ou do grau de ponderação, a ORDEM DE SERVIÇO será devolvida ao FISCAL REQUISITANTE para que justifique ou refaça a indicação conforme entendimento A indicação do FATOR DE PONDERAÇÃO- FP é obrigatória para a abertura de ORDEM DE SERVIÇO, sendo de total responsabilidade e com critério de entendimento do CONTRATANTE, não cabendo à CONTRATADA nenhuma interferência direta ou indireta para a definição do fator de ponderação, salvo o previsto no subitem A composição da quantidade de MAT para cada atividade relacionada ao grau do FP está prevista no PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A. 3.2 O FATOR DE CONHECIMENTO INTERNO E MATURIDADE- FACIM é um indicador que baliza a perspectiva de definição do conhecimento interno e da maturidade para a execução das atividades. Este indicador tem o objetivo de criar um parâmetro que avalia o nível de maturidade e conhecimento do Inep que é transferido para o contexto da necessidade em que a atividade será inserida. Para apoiar na definição do FACIM seguem como referência os seguintes critérios: DEFINIDO: As atividades são apoiadas por fortes subsídios de conhecimento e maturidade que serão temporariamente transferidos à CONTRATADA para auxiliar na execução das atividades. Considera-se como referência, entre outros: contexto em que as atividades têm necessidades, expectativas e restrições, tanto do serviço quanto de seus artefatos, identificadas; soluções são selecionadas para o serviço ou artefatos, com base em cenários definidos e em critérios identificados; apoiadas por guias estabelecidos e mantidos pelo Inep; alternativas de solução aceitáveis para o problema ou questão são identificadas; os riscos são identificados e documentados, incluindo seu contexto, condições de execução e possíveis consequências para as atividades e as partes interessadas PARCIALMENTE DEFINIDO: As atividades são apoiadas por relativo subsídio de conhecimento e maturidade que serão temporariamente transferidos à CONTRATADA para auxiliar na execução das atividades. Considera-se como referência, entre outros: contexto em que as atividades têm necessidades, expectativas e restrições, tanto do serviço quanto de seus artefatos, parcialmente identificadas; soluções são selecionadas para o serviço ou artefatos, com base em cenários parcialmente definidos e em critérios parcialmente identificados; não são apoiadas por guias estabelecidos e mantidos 41

42 pelo Inep; alternativas de solução aceitáveis para o problema ou questão são parcialmente identificadas; os riscos são parcialmente identificados e parcialmente documentados, incluindo seu contexto, condições de execução e possíveis consequências para as atividades e as partes interessadas INDEFINIDO: Não há subsídio de conhecimento e maturidade que possam ser temporariamente transferidos à CONTRATADA para auxiliar na execução das atividades. Considera-se como referência, entre outros: contexto em que as atividades têm necessidades, expectativas e restrições, tanto do serviço quanto de seus artefatos, não identificadas; soluções são selecionadas para o serviço ou artefatos, com base em cenários não definidos e em critérios não identificados; não é apoiado por guias estabelecidos e mantidos pelo Inep; alternativas de solução aceitáveis para o problema ou questão não são identificadas; os riscos não são identificados e documentados. TABELA 4-Tabela de referência para balizar o FACIM FACIM ID FATOR Definido D 0,5 Parcialmente- Definido PD 1 Indefinido I 1, A indicação de qualquer dos critérios no nível de PARCIALMENTE DEFINIDO ou INDEFINIDO deverá ser justificada por escrito pelo FISCAL REQUISITANTE na ORDEM DE SERVIÇO e, após avaliação do FISCAL TÉCNICO e do GESTOR DO CONTRATO será autorizada, ou não, ter a indicação dos referidos critérios Caso o FISCAL TÉCNICO ou GESTOR DO CONTRATO entenderem não ser procedente alguma indicação da maturidade ou conhecimento interno, a ORDEM DE SERVIÇO será devolvida ao FISCAL REQUISITANTE para que justifique ou refaça a indicação conforme entendimento Durante a execução do contrato uma atividade que inicialmente possuía um FACIM INDEFINIDO poderá ter essa classificação alterada para PARCIALMENTE-DEFINIDO ou DEFINIDO, pois o FACIM tenderá ao nível DEFINIDO na medida em que as atividades forem sendo executadas, agregando maturidade na execução dos serviços e ampliando a base de conhecimento do Inep A indicação do Fator de Conhecimento Interno e Maturidade- FACIM é obrigatória para a abertura de ORDEM DE SERVIÇO, sendo de total responsabilidade e com critério de entendimento do CONTRATANTE, não cabendo à CONTRATADA nenhuma interferência direta ou indireta para a definição, salvo o previsto no subitem A Quantidade de MAT para cada atividade é definida seguindo a seguinte fórmula: QMA=FPQtd x FACIM Onde: QMA= Quantidade de MAT por Atividade FPQtd= Quantidade de MAT por grau do Fator de Ponderação, conforme o PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A. FACIM =Fator de Conhecimento Interno e Maturidade, conforme a Tabela 04 deste TERMO DE REFERÊNCIA. 3.4 No PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A, temos as atividades previstas para execução dos serviços. Foram definidas e atribuídas as quantidades de MAT para cada grau do FP e o QMA para cada valor do FACIM. 42

43 Ressalta-se que, apesar de as atividades terem diferentes critérios que balizam sua variação conforme a aplicação, isso não as descaracteriza como sendo comuns ou usuais de mercado. Conforme prevê o Parágrafo único do artigo 1º da Lei , de 17 de julho de 2002: Consideram-se bens e serviços comuns, para os fins e efeitos deste artigo, aqueles cujos padrões de desempenho e qualidade possam ser objetivamente definidos pelo edital, por meio de especificações usuais no mercado. Ainda, conforme o parágrafo segundo do artigo 9º do Decreto de 12 de maio de 2010: 2º será considerado comum o bem ou serviço cuja especificação estabelecer padrão objetivo de desempenho e qualidade e for capaz de ser atendido por vários fornecedores, ainda que existam outras soluções disponíveis no mercado. Ressalta-se, que todas as empresas deverão realizar vistoria técnica nas dependências do Inep, conforme previsto neste TERMO DE REFERÊNCIA no subitem 10.4, e ao final da vistoria, além do TERMO DE CONFIDENCIALIDADE- Anexo K também assinarão o TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA- Anexo M. No caso do INEP, mesmo se tratando de demanda por produtos, focada em qualidade, em função das políticas de gestão de segurança implantadas que define os conceitos de utilização, monitoração, manutenção e segurança dos recursos de TI, é imprescindível que os recursos técnicos envolvidos para execução dos serviços estejam alocados em área interna definida, sendo gerenciados exclusivamente pelo representante da empresa contratada. Esses recursos humanos deverão conhecer o funcionamento dos negócios internos da DTDIE e as respectivas áreas do Inep e executar os procedimentos de acordo com as regras de segurança, não sendo possível, para a maioria das tarefas, execução ou operacionalização remota. O mesmo ocorre com manutenções e monitorações que requeiram utilização de senhas privilegiadas ou que possam manipular ou ver informações de serviços ou sistemas críticos. Portanto, a utilização in-loco de um quadro mínimo de recursos profissionais para execução das demandas e atividades de assessoria tecnológica será necessária e exigida, buscando assim, não só a prestação dos serviços com a qualidade definida, como também a sua continuidade em conformidade com as atividades fins da Organização. Os projetos da Organização tornaram a área de TI primordial e crítica para o atendimento das atividades fins, de tal forma que, em casos de paralisações dos sistemas de TI, ficam comprometidas as atividades da missão institucional da Organização. Por ser crítico, contínuo e essencial, justifica definição de margens de glosas e multas, com a perspectiva de possibilitar a garantia de sua continuidade e a execução dos procedimentos com a eficiência e eficácia necessária para a sua estabilização. Com relação ao planejamento da organização, esta licitação insere-se como um componente integrado a 43

44 diversas outras medidas para que se possa dar curso à estratégia de modernização de gestão da informação como delineado no Plano Diretor de Tecnologia da Informação- PDTI. No que tange à modalidade da licitação Pregão, os serviços demandados, especificamente relacionados nos anexos deste TERMO DE REFERÊNCIA, são rotinas de natureza comum na área de informática, definidos como contínuos, essenciais e obrigatórios a qualquer estrutura tecnológica, ou seja, de características tipicamente da área de TI. Portanto, tratam-se de atividades rotineiras e obrigatórias no ambiente de Tecnologia da Informação, comuns a qualquer parque desta natureza. Nesse sentido, a modalidade definida está embasada por decisões e recomendações do TCU, conforme pode ser entendido no Acórdão 1.114/2006 Plenário, onde se destaca: [Relatório]20... O objeto pode portar complexidade técnica e ainda assim ser comum, no sentido de que essa técnica é perfeitamente conhecida, dominada e oferecida pelo mercado. Sendo tal técnica bastante para atender às necessidades da Administração, a modalidade pregão é cabível a despeito da maior sofisticação do objeto 21. (...) Bens e serviços com complexidade técnica, seja na sua definição ou na sua execução, também são passíveis de ser contratados por meio de pregão. O que se exige é que a técnica neles envolvida seja conhecida no mercado do objeto ofertado, possibilitando, por isso, sua descrição de forma objetiva no edital. Portanto, considerando que a Lei /2004 e o Decreto 3.693/2000 admitiram o uso de Pregão para bens e serviços de informática, e ainda que, na licitação do tipo "menor preço", não interessa mais à Administração valorar a variação técnica das propostas que estejam acima dos requisitos técnicos mínimos aceitáveis e previamente fixados, permitindo considerar que todas as propostas qualificadas são tecnicamente equivalentes (mesmo valor para o adquirente), porque o excesso de qualidade técnica não é valorável, já que o edital fixará os requisitos técnicos mínimos aceitáveis para os critérios de prazo de entrega, suporte de serviços, qualidade, padronização, compatibilidade e especificação de desempenho, satisfazendo assim os critérios para sua definição e as recomendações do TCU que preconiza nesse sentido. 4 ESPECIFICAÇÕES TÉCNICA 4.1 CONSIDERAÇÕES GERAIS Para fins de execução do contrato, a CONTRATADA deverá atender os seguintes requisitos técnicos, além dos detalhados no PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A, e também a outras previsões constantes neste Termo de Referência. 4.2 REQUISITOS INTERNOS FUNCIONAIS A CONTRATADA deverá ter conhecimento e capacitação técnica para prestar os serviços abaixo relacionados, que poderão ser demandados a qualquer tempo por meio das ORDENS DE SERVIÇO, de acordo com o PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A: 44

45 Apoiar a DTDIE na definição, implantação, averiguação, evolução e manutenção dos padrões de arquitetura de sistemas Definir, entre outras coisas, onde implementar, onde e como persistir informações e as tecnologias que devem ser utilizadas Avaliar a qualidade nos códigos e artefatos de sistemas primando pela otimização do desempenho e pela segurança Formular proposta de melhorias para ambiente de desenvolvimento, teste e produção de sistemas do Inep Modelar e prospectar soluções inovadoras e integradoras de sistemas Analisar e prospectar resolução de incidentes e problemas nos sistemas em produção Prestar serviços de suporte as atividades de análise de negócio para desenvolvimento de sistemas Definir e documentar os requisitos do negócio incluindo a necessidade do negócio, capacidades requeridas, escopo da solução e plano de negócios Avaliar e documentar lapsos de capacidade, identificando quais são as capacidades necessárias para a organização atender à necessidade do negócio Compreender e documentar as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam Elaborar relatórios gerenciais de serviços, apresentando-os ao CONTRATANTE, constando dentre outras informações, os indicadores e metas de níveis de serviços acordados e alcançados, recomendações técnicas, administrativas e gerenciais para as próximas demandas e demais informações relevantes para as novas ordens de serviços, tais como: todas as atividades executadas, passo a passo e em detalhe, para a conclusão dos serviços; o tempo de execução para cada atividade descrita no relatório; os impedimentos que ocorreram na execução; quando couber, sugestões para melhorias nas atividades e/ou no processo. 4.3 REQUISITOS INTERNOS NÃO FUNCIONAIS A CONTRATADA deverá atender às definições e premissas técnicas e recomendações do Inep para execução dos procedimentos abaixo relacionados demandados pelas ORDENS DE SERVIÇO (OS), observando, além das recomendadas nas Tarefas, as seguintes: A execução de atividades de assessoria tecnológica deverá ser realizada nas dependências do CONTRATANTE ou quando houver forte dependência nos objetivos de negócio, excepcionalmente, nas dependências de outros Órgãos nos casos em que a DTDIE entender como conveniente A CONTRATADA deverá manter uma equipe técnica mínima, suficiente para recepcionar as ORDENS DE SERVIÇO e atender nos prazos definidos A equipe deverá estar distribuída conforme as áreas previstas no TERMO DE REFERÊNCIA dispostas no subitem 2.1.2, especificadas pelas atividades e em acordo com os perfis profissionais, dispostos no subitem , que os serviços requeiram Deverão considerar ainda a possibilidade de executar os serviços nas dependências do Inep, sempre com a conivência e mediante autorização, durante as madrugadas, em feriados e finais de semana Deverá manter um PREPOSTO, com conhecimento técnico suficiente, que fará internamente o controle da qualidade de execução das ORDENS DE SERVIÇO, assim como a conferência, antes da entrega da 45

46 atividade e artefato Considerar ainda, o PREPOSTO, com especialização em gerência de projetos e conhecimento de Análise de Sistemas, Análise de Arquitetura de Sistemas e Análise de Negócio para Sistemas, em tempo integral, para efetuar as negociações com o FISCAL REQUISITANTE, FISCAL TÉCNICO e GESTOR DO CONTRATO, além de ser o único contato da CONTRATADA com as equipes técnicas do CONTRATANTE, podendo, quando entender necessário, ser acompanhado por especialistas técnicos de sua equipe As atividades de assessoria tecnológica deverão ser realizadas em conformidade com os horários e períodos programados e determinados pelo CONTRATANTE Serviços e atividades de assessoria tecnológica deverão ser realizados prioritariamente durante o expediente normal da organização Em caso de risco de descontinuidade por motivos de manutenções evolutivas e pró-ativas, as mesmas deverão ser realizadas prioritariamente fora do expediente normal da organização, ou seja, durante as madrugadas ou em finais de semana e feriados Efetuar a transferência de conhecimento para a equipe técnica do CONTRATANTE, de todos os novos serviços implantados e/ou modificados, mediante documentação técnica em repositório adotado pelo CONTRATANTE para esse fim Toda a documentação produzida pela CONTRATADA em decorrência dos procedimentos executados passará a ser de propriedade do Inep a partir do aceite definitivo das ORDENS DE SERVIÇO ou ORDENS DE SERVIÇO DE GARANTIA Executar todos os serviços, tarefas e atividades demandadas pelo CONTRATANTE, dentro do prazo negociado e especificado nas ORDENS DE SERVIÇO, atendendo o padrão de qualidade exigido Apresentar relatório de execução dos serviços que foram realizados pela CONTRATADA, demonstrando os resultados promovidos pelos serviços executados Realizar todos os trabalhos sem que haja a necessidade de parada dos sistemas em produção, exceto as predeterminadas com a equipe do CONTRATANTE. Do mesmo modo, deverão ser observadas as rotinas internas da Organização, cujo andamento em hipótese nenhuma deverá ser prejudicado em razão de quaisquer atividades mencionadas Acompanhar diariamente a qualidade e os níveis de serviços alcançados com vistas a efetuar eventuais ajustes e correções Planejar, definir e especificar atividades e montar os modelos globais de execução, negociando com o CONTRATANTE a inclusão de novas atividades necessárias nas fases propostas A CONTRATADA deverá atender os chamados de assessoria tecnológica de sistemas, realizados mediante sistema específico de solicitação, a ser apresentado à época da vistoria e/ou contratação, devendo atender aos prazos de atendimento e qualidade acordados entre o CONTRATANTE e a CONTRATADA Caso o atendimento não cumpra os prazos e/ou qualidade acordados, a CONTRATADA incorrerá nas penalidades previstas no contrato, conforme subitem Quando os serviços de assessoria tecnológica de sistemas dependerem de outras equipes que não a da CONTRATADA, os prazos serão suspensos a partir do encaminhamento, voltando a contagem tão logo sejam devolvidos pela área responsável, devendo ter o aceite da equipe fiscalizadora por meio de andamento padronizado. 4.4 REQUISITOS EXTERNOS 46

47 4.4.1 São requisitos exigidos da CONTRATADA com relação ao PADRÃO DE QUALIDADE DOS SERVIÇOS: As tarefas deverão ser realizadas atendendo aos seguintes padrões definidos pelo Inep e descritos em documentos anexos a este TERMO DE REFERÊNCIA: Guia de Escrita de Caso de Uso do Inep; Guia de Caso de Uso; Guia de Arquitetura; Guia da Contagem de Ponto de Função; Guia de Desenvolvimento; Guia ETL; Guia de Modelagem Dimensional; Guia de Segurança da Informação; Guia de Banco de Dados; Metodologia de Gestão e Desenvolvimento de Sistemas; Política de Segurança da Informação e Comunicação do Inep Quando não houver critérios técnicos ou processos previstos nos padrões adotados pelo Inep, serão adotadas como referência as melhores práticas de gestão e qualidade, dentre as quais: PMBOK, ISO 9001: 2000, ITIL, COBIT, ISO 17799, ISO e ISO Os serviços que venham a ser desenvolvidos/mantidos pelo instrumento oriundo deste processo de contratação deverão aderir ao MODELO DE ACESSIBILIDADE EM GOVERNO ELETRÔNICO e- MAG, e, sempre que possível, aos padrões de INTEROPERABILIDADE DE GOVERNO ELETRÔNICO e-ping Os certificados e experiências exigidos para os perfis profissionais deverão ser apresentados pela CONTRATADA conforme subitem , para cada recurso alocado para a contratação Os certificados e experiências exigidos para os perfis profissionais estão descritos no PERFIS PROFISSIONAIS E FORMAÇÃO EXIGIDA- ANEXO P Prestar os serviços dentro dos parâmetros e rotinas estabelecidos neste processo de contratação, com observância às recomendações aceitas pela boa técnica, normas e legislação, bem como observar conduta adequada na utilização dos materiais, equipamentos, ferramentas e utensílios Manter, durante todo o período de vigência do contrato, todas as condições que ensejaram sua contratação Fornecer toda a mão de obra qualificada na execução dos serviços para assessoria tecnológica de sistemas e em quantidade suficiente para atender aos critérios de qualidade exigidos neste Termo de Referência É da CONTRATADA a responsabilidade pela entrega dos produtos com a qualidade exigida, sujeitando-se às penalidades e glosas previstas contratualmente, cabendo à mesma direcionar tantos recursos quanto forem necessários para atender as exigências de qualidade determinadas para cada ORDEM DE SERVIÇO Fiscalizar regularmente os seus recursos técnicos designados para a prestação dos serviços verificando 47

48 as condições em que as atividades estão sendo realizadas Refazer todos os serviços que, a juízo do representante do CONTRATANTE, não forem considerados satisfatórios, sem que caiba qualquer acréscimo no custo contratado, independentemente das penalidades previstas nas ORDENS DE SERVIÇO e INDICADORES DE NÍVEIS DE SERVIÇO fixados Executar fielmente o objeto contratado, de acordo com as normas legais, em conformidade com a proposta apresentada e com as orientações do CONTRATANTE, observando sempre os critérios de qualidade São requisitos exigidos com relação à POLÍTICA DE SEGURANÇA DA INFORMAÇÃO: A CONTRATADA deverá obedecer aos critérios, padrões, políticas, normas e procedimentos operacionais adotados ou que venham a ser adotados pelo CONTRATANTE Manter sigilo, sob pena de responsabilidades civis, penais e administrativas, sobre todo e qualquer assunto de interesse do CONTRATANTE ou de terceiros de que tomar conhecimento em razão da execução do objeto deste TERMO DE REFERÊNCIA devendo orientar seus empregados nesse sentido A CONTRATADA, quando da assinatura do contrato, por meio de seu representante assinará o TERMO DE COMPROMISSO- Anexo N em que se responsabilizará pela manutenção de sigilo e confidencialidade das informações a que possa ter acesso em decorrência da contratação A CONTRATADA fica sujeita à sanção prevista no subitem em caso de descumprimento do TERMO DE COMPROMISSO A CONTRATADA deverá apresentar para cada funcionário que vier a executar atividades referentes ao objeto da contratação, o TERMO DE CIÊNCIA- Anexo L, em que seus profissionais declaram estar cientes das responsabilidades pela manutenção de sigilo e confidencialidade, bem como também declaram que não farão uso em benefício próprio de nenhum dos recursos disponíveis no Inep, tais como telefones, impressoras, fax, entre outros Promover o afastamento, no prazo máximo de 24 (vinte e quatro) horas após o recebimento da notificação, de qualquer dos seus recursos técnicos que não correspondam aos critérios de confiança ou que perturbe a ação da equipe de fiscalização do CONTRATANTE Responsabilizar-se pelos materiais, produtos, ferramentas, instrumentos e equipamentos disponibilizados para a execução dos serviços, não cabendo ao CONTRATANTE qualquer responsabilidade por perdas decorrentes de roubo, furto ou outros fatos que possam vir a ocorrer Não transferir a outrem no todo ou em parte o objeto do presente contrato sem prévia e expressa anuência do CONTRATANTE Não veicular publicidade acerca dos serviços contratados, sem prévia autorização, por escrito, do CONTRATANTE Manter em caráter confidencial, mesmo após o término do prazo de vigência ou rescisão do contrato, as informações relativas à política de segurança adotada pelo CONTRATANTE Não efetuar, sob nenhum pretexto, a transferência de qualquer responsabilidade da CONTRATADA para outras entidades, seja fabricantes, técnicos, subempreiteiros etc., sem a anuência expressa e por escrito da área administrativa do CONTRATANTE Executar todos os procedimentos e processos de segurança necessários e definidos na legislação pertinente ou padrões adotados pelo Inep Submeter seus recursos técnicos aos regulamentos de segurança e disciplina instituídos pelo CONTRATANTE, durante o tempo de permanência nas suas dependências Responsabilizar-se pelo pagamento das faturas dos ramais telefônicos disponibilizados aos seus 48

49 profissionais alocados aos serviços desta contratação Será fornecido, desde que haja disponibilidade e mediante autorização do GESTOR DO CONTRATO, ao profissional alocado na contratação em questão à sua disposição um ramal e uma senha exclusiva para uso do mesmo A equipe de Telefonia do Inep, no início de cada mês, disponibilizará uma fatura por ramal na qual constarão as chamadas e respectivos valores deste ramal O GESTOR DO CONTRATO emitirá uma Guia de Recolhimento da União (GRU), que deverá ser paga pela CONTRATADA no prazo estipulado na GRU Para que a CONTRATADA atenda aos requisitos exigidos com relação às NORMAS E PROCEDIMENTOS DE CONTROLE DE ACESSO, esta deverá: Fornecer aos seus recursos técnicos todos os equipamentos de proteção individual e coletiva, observando e cumprindo as normas relacionadas com a segurança e higiene no trabalho Responsabilizar-se pelo credenciamento e descredenciamento de acesso às dependências do CONTRATANTE, assumindo quaisquer prejuízos porventura causados por seus recursos técnicos Solicitar, por escrito, credenciamento e autorização de acesso para os recursos técnicos da CONTRATADA, através do preenchimento do TERMO DE CREDENCIAMENTO- Anexo I Informar e solicitar, no prazo máximo de 24 (vinte e quatro) horas, o descredenciamento dos recursos desvinculados da prestação de serviços com o CONTRATANTE Devolver todos os recursos e equipamentos utilizados pela CONTRATADA, como crachás, cartões certificadores, pen-drives e outros, de propriedade do CONTRATANTE, juntamente com o TERMO DE DESCREDENCIAMENTO- Anexo J São requisitos mínimos exigidos da CONTRATADA com o objetivo de aperfeiçoamento do processo de METODOLOGIA E PADRONIZAÇÃO: Elaborar documentos, relatórios gerenciais e outros, referentes ao acompanhamento da execução das ORDENS DE SERVIÇO, padronizados pelos templates, MODELO DE ORDEM DE SERVIÇO- Anexo B, (sistematizados ou não) para cada tipo de documentação ou processo operacional Dar conhecimento da documentação técnica de processos de execução de serviços aos seus recursos técnicos alocados, de acordo com a capacitação de cada um, e fazer com que as atividades sejam executadas conforme os procedimentos definidos pelo CONTRATANTE Promover a transferência de conhecimento para os técnicos indicados pelo Inep, de forma a permitir a completa gerência, operação, monitoramento e otimização da solução Formalizar o encerramento dos serviços, com documentação, procedimentos e termo de entrega Comunicar ao CONTRATANTE, por escrito, qualquer anormalidade verificada na entrega dos serviços e artefatos, prestando ao Inep os devidos esclarecimentos, sempre que solicitados Realizar os serviços de modo que não prejudiquem o andamento normal das atividades do CONTRATANTE em horário de seu expediente normal A CONTRATADA deverá considerar que os serviços serão realizados em horário comercial de segunda à sexta-feira, não excluída a possibilidade de atendimentos aos finais de semanas, feriados ou em horários noturnos Implantar adequadamente o planejamento, a execução e a supervisão permanente dos serviços demandados, de forma a obter uma operação correta e eficaz, realizando os serviços de forma meticulosa e constante, mantendo sempre em perfeita ordem todas as dependências do 49

50 CONTRATANTE Comunicar às unidades do CONTRATANTE responsáveis pela fiscalização do contrato, por escrito, qualquer anormalidade, bem como atender prontamente o que lhe for solicitado e exigido Responder, por escrito, no prazo máximo de 48 (quarenta e oito) horas úteis, a quaisquer esclarecimentos de ordem técnica, pertinentes à execução dos serviços, que venham porventura a ser solicitado pelo CONTRATANTE Colocar seu corpo técnico à disposição do CONTRATANTE para orientação quanto à execução dos serviços, sempre que solicitado Faturar somente as ORDENS DE SERVIÇO efetivamente concluídas, atestadas e aceitas pelo CONTRATANTE Acatar as determinações feitas pela fiscalização do CONTRATANTE no que tange ao cumprimento do objeto do CONTRATO Prestar, de imediato, todos os esclarecimentos solicitados pela fiscalização do CONTRATANTE no que diz respeito ao cumprimento do objeto contratado São requisitos exigidos com relação às NORMAS GERAIS DOS RECURSOS CONTRATADOS: A CONTRATADA fica terminantemente proibida de utilizar qualquer servidor do CONTRATANTE na execução dos serviços contratados, nos termos do que estabelece o Art. 9º. Inciso III, da Lei n /1993, sob pena de imediata rescisão contratual Alocar um responsável técnico, com especialidade em gerência de projetos e serviços de assessoria tecnológica de sistemas, doravante denominado de PREPOSTO O PREPOSTO ou seu substituto deverá estar disponível nas dependências do CONTRATANTE, nos dias úteis, no horário comercial, e acessível por contato telefônico em qualquer outro horário, inclusive em feriados e finais de semana O PREPOSTO deverá acompanhar a execução das Ordens de Serviços em vigor O PREPOSTO deverá assegurar que as determinações do CONTRATANTE sejam disseminadas junto à CONTRATADA com vistas à alocação dos profissionais necessários para execução das ORDENS DE SERVIÇO e às ORDENS DE SERVIÇO DE GARANTIA O PREPOSTO deverá informar ao CONTRATANTE sobre problemas de quaisquer naturezas que possam impedir o bom andamento dos serviços O PREPOSTO deverá executar os procedimentos administrativos referentes aos recursos alocados para execução dos serviços contratados O PREPOSTO deverá acompanhar e manter-se atualizado quanto às ORDENS DE SERVIÇO e às ORDENS DE SERVIÇO DE GARANTIA O PREPOSTO deverá atender às instruções do CONTRATANTE quanto à execução e aos horários de realização dos serviços, permanência e circulação de pessoas nas dependências do Inep Apresentar seus recursos técnicos com pontualidade, de acordo com os horários fixados pelo CONTRATANTE, para fins de execução dos serviços contratados Responsabilizar-se pela limpeza e conservação dos ambientes onde desempenhe seus serviços Responsabilizar-se por danos causados ao patrimônio do CONTRATANTE, ou de terceiros, ocasionados por seus empregados, em virtude de dolo ou culpa, durante a execução do objeto contratado. 50

51 Fornecer todos os materiais necessários à perfeita instalação, execução e funcionamento de suas atividades Responsabilizar-se pelos danos causados ao Inep ou a terceiros, decorrentes de sua culpa ou dolo, não excluindo ou reduzindo essa responsabilidade à fiscalização, ou o acompanhamento da entrega dos insumos pelo CONTRATANTE Cumprir, às suas próprias expensas, todas as cláusulas contratuais que definam suas obrigações Responsabilizar-se por quaisquer acidentes de que possam ser vítimas seus empregados e PREPOSTOS, quando nas dependências do CONTRATANTE, devendo adotar as providências que, a respeito, exigir a legislação em vigor A CONTRATADA assumirá, sem que haja responsabilização do CONTRATANTE, todos os ENCARGOS, TRIBUTOS e MULTAS, devendo: Arcar com todas as despesas relativas à execução dos serviços, tais como mão-de-obra, ferramentas, equipamentos, taxas, emolumentos, encargos sociais, infração cometida por seus recursos técnicos (inclusive com as glosas previstas) quando da execução dos serviços especificados nas ordens de serviços Responder por todo e qualquer dano ou prejuízo eventualmente causado ao CONTRATANTE como consequência de atos e fatos imputáveis a seus recursos técnicos Assumir a responsabilidade por todos os encargos previdenciários e obrigações sociais previstas na legislação social e trabalhista em vigor, obrigando-se a saldá-las na época própria, vez que os seus empregados não manterão nenhum vínculo empregatício com o CONTRATANTE Assumir a responsabilidade por todas as providências e obrigações estabelecidas na legislação específica de acidentes de trabalho, quando, em ocorrência da espécie, forem vítimas os seus empregados durante a execução do contrato, ainda que acontecido em dependência do CONTRATANTE Assumir a responsabilidade por todos os encargos de possível demanda trabalhista, civil ou penal, relacionada à execução deste contrato, originariamente ou vinculada por prevenção, conexão ou contingência Assumir a responsabilidade por todos os encargos fiscais e comerciais resultantes desta contratação A inadimplência da CONTRATADA, com referência aos encargos estabelecidos no subitem anterior, não transfere à Administração do CONTRATANTE a responsabilidade de pagamento, nem pode onerar o objeto deste contrato, razão pela qual a CONTRATADA renuncia expressamente a qualquer vínculo de solidariedade, ativa ou passiva, com o CONTRATANTE Assumir a responsabilidade pelo pagamento de eventuais multas aplicadas por quaisquer autoridades federais, estaduais e municipais, em consequência de fato a ela imputável e relacionada com a execução do objeto deste contrato Assumir a responsabilidade por todos os prejuízos advindos de perdas e danos, incluindo despesas judiciais e honorários advocatícios resultantes de ações judiciais que o CONTRATANTE for compelido a responder por força desta contratação. 5 MODELO DE PRESTAÇÃO DE SERVIÇO E METODOLOGIA DE TRABALHO 5.1 Todo e qualquer serviço a ser demandado, somente será executado pela CONTRATADA mediante uma ORDEM DE SERVIÇO (OS)- Anexo B, requerida pelo FISCAL REQUISITANTE, verificada pelo FISCAL TÉCNICO e emitida pelo GESTOR DO CONTRATO. As ORDENS DE SERVIÇO serão consideradas como 51

52 adendos ao Contrato Para os casos emergenciais haverá prazo posterior à solicitação de até 8 (oito) horas úteis para registro da OS. 5.2 A OS descreve o serviço a ser executado, os artefatos a serem entregues, o prazo para a execução, as condições de aceite dos artefatos, as atividades necessárias e a quantidade de MAT prevista, conforme PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A. 5.3 Os serviços somente serão considerados como finalizados após entrega dos artefatos solicitados para a VERIFICAÇÃO DA QUALIDADE, por meio de registro de recebimento na OS por parte do solicitante, aqui denominado de FISCAL REQUISITANTE. 5.4 Para identificar a conformidade dos serviços entregues pela CONTRATADA, o recebimento será classificado, pelo Inep, considerando os seguintes critérios: ACEITO: quando a(s) ORDEM(NS) DE SERVIÇO(s) e o(s) ARTEFATO(s) entregue(s) for(em) recebido(s) integralmente pelo FISCAL REQUISITANTE e, após verificação da qualidade, ser(em) aceito(s) não cabendo ajustes NÃO ACEITO: quando a(s) ORDEM(NS) DE SERVIÇO(s) e o(s) ARTEFATO(s) ou o(s) artefato(s) entregue(s) for(em) recebido(s) integralmente pelo FISCAL REQUISITANTE e, após verificação da qualidade, ser(em) rejeitado(s) cabendo ajustes ou retificações; sujeitando-se a CONTRATADA às GLOSAS estabelecidas para o caso. 5.5 Caso um artefato desenvolvido pela CONTRATADA e entregue para a VERIFICAÇÃO DA QUALIDADE receba a indicação de NÃO ACEITO pelo CONTRATANTE, a CONTRATADA deverá promover os ajustes necessários em prazo estabelecido pelo FISCAL REQUISITANTE contado a partir da notificação por parte do CONTRATANTE. 5.6 A CONTRATADA deverá garantir os serviços pelo período de um ano, a partir da indicação de ACEITO na OS, pelo FISCAL REQUISITANTE. 5.7 Caberá à CONTRATADA, no período de garantia, sem ônus para o Inep, realizar toda a correção decorrente de erros ou falhas cometidas na execução dos serviços contratados e/ou decorrentes de integração e adequação sistêmica, desde que, comprovadamente, não tenham se dado em função de falhas nas especificações ou descrição das necessidades feitas pelo Inep. 5.8 Estão cobertos pela garantia todos os serviços executados, bem como todos os artefatos relacionados Será emitida uma ORDEM DE SERVIÇO DE GARANTIA (OSG)-Anexo C específica para os itens em garantia, a qual se aplicará os mesmos critérios de execução e de VERIFICAÇÃO DA QUALIDADE previstos para as OS, além de serem computadas para aferição de glosas e multas. 5.9 O fluxo de solicitação e execução dos serviços ocorrerá da seguinte maneira: O FISCAL REQUISITANTE solicita a execução dos serviços por meio de uma ORDEM DE SERVIÇO- OS, indicando, no mínimo, as seguintes informações na OS: a área de atividade, conforme áreas previstas no Termo de Referência; a atividade necessária, conforme PORTFÓLIO DE ATIVIDADES E ARTEFATOS; Novas atividades poderão ser solicitadas, desde que sejam previamente incluídas e metrificadas no PORTFÓLIO DE ATIVIDADES E ARTEFATOS os artefatos que deverão ser entregues, conforme PORTFÓLIO DE ATIVIDADES E ARTEFATOS; Novos artefatos poderão ser solicitados, desde que sejam previamente incluídos no PORTFÓLIO DE ATIVIDADES E ARTEFATOS. 52

53 prazo para a execução das atividades e entrega dos artefatos; quantidade de MAT prevista, conforme PORTFÓLIO DE ATIVIDADES E ARTEFATOS, para a execução da OS; o FATOR DE PONDERAÇÃO- FP previsto para a atividade conforme PORTFÓLIO DE ATIVIDADES E ARTEFATOS; o FATOR DE CONHECIMENTO INTERNO E MATURIDADE- FACIM conforme PORTFÓLIO DE ATIVIDADES E ARTEFATOS; A OS é encaminhada para o FISCAL TÉCNICO que verificará se a solicitação está em conformidade com o TERMO DE REFERÊNCIA e o CONTRATO Havendo desconformidade o FISCAL TÉCNICO solicitará ao FISCAL REQUISITANTE que providencie as alterações necessárias na OS para as devidas adequações Não havendo desconformidades na OS, o FISCAL TÉCNICO encaminhará ao GESTOR DO CONTRATO para emitir a OS ao PREPOSTO da CONTRATADA O PREPOSTO não poderá rejeitar a execução de nenhuma OS ou OSG, porém poderá questionar e solicitar adequações na OS ou OSG, desde que aderentes ao CONTRATO e ao TERMO DE REFERÊNCIA, para garantir a qualidade das entregas. Sempre cabendo ao GESTOR DO CONTRATO, ao FISCAL TÉCNICO e ao FISCAL REQUISITANTE acatar ou não as requisições do PREPOSTO O PREPOSTO terá prazo máximo de 15 minutos, após a emissão da OS, para questionar ou solicitar adequações junto ao GESTOR DO CONTRATO O GESTOR DO CONTRATO juntamente com o FISCAL TÉCNICO e o FISCAL REQUISITANTE analisarão os questionamentos ou solicitações do PREPOSTO e, em acatando, providenciarão as adequações necessárias na OS emitindo-a novamente ao PREPOSTO O PREPOSTO deverá distribuir internamente as OS conforme a área de atividade solicitada Após a execução da OS, a CONTRATADA deverá entregar também o RELATÓRIO DE EXECUÇÃO DE SERVIÇO-ANEXO D descrevendo, detalhadamente: todas as atividades executadas, passo a passo e em detalhe, para a conclusão dos serviços; o tempo de execução para cada atividade descrita no relatório; os impedimentos que ocorreram na execução; quando couber, sugestões para melhorias nas atividades e/ou no processo Após a execução do serviço, o PREPOSTO deverá encaminhar a OS, os artefatos solicitados e o RELATÓRIO DE EXECUÇÃO DE SERVIÇO ao FISCAL REQUISITANTE que deverá proceder a VERIFICAÇÃO DA QUALIDADE O FISCAL REQUISITANTE juntamente com o FISCAL TÉCNICO procederá, após receber a OS e o(s) artefato(s) solicitado(s), a VERIFICAÇÃO DA QUALIDADE dos serviços e artefatos conforme padrões e critérios de qualidade, compatibilidade técnica e de conformidade, segundo as metodologias e padrões adotados pelo Inep. Após a verificação poderá: estando os artefatos e a OS de acordo com os padrões e critérios de qualidade, compatibilidade técnica e de conformidade, segundo as metodologias e padrões adotados pelo Inep, o FISCAL TÉCNICO indica o ACEITO na OS e encaminha ao FISCAL REQUISITANTE que procederá a VERIFICAÇÃO DA QUALIDADE; estando o(s) artefato(s) e a OS em desacordo com os padrões e critérios de qualidade, compatibilidade 53

54 técnica e de conformidade, segundo as metodologias e padrões adotados pelo Inep, o FISCAL TÉCNICO indica o NÃO ACEITO na OS, justifica os motivos da rejeição e encaminha ao FISCAL REQUISITANTE que procederá ao PREPOSTO para os ajustes necessários para conclusão da OS; O prazo para a CONTRATADA corrigir ou ajustar os serviços ou artefatos que obtiveram indicação NÃO ACEITO procederá conforme subitem estando o(s) artefato(s) e a OS de acordo com o solicitado, o FISCAL REQUISITANTE indica o ACEITO na OS e encaminha, juntamente com o RELATÓRIO DE EXECUÇÃO DE SERVIÇO, ao GESTOR DO CONTRATO que procederá a CONCLUSÃO da OS; estando o(s) artefato(s) e a OS em desacordo com o solicitado, o FISCAL REQUISITANTE indica o NÃO ACEITO na OS, justifica os motivos da rejeição e encaminha ao PREPOSTO que procederá aos ajustes necessários para conclusão da OS; O prazo para a CONTRATADA corrigir ou ajustar os serviços ou artefatos que obtiveram indicação NÃO ACEITO procederá conforme subitem A indicação de NÃO ACEITO na OS será registrada para aferição dos INDICADORES DE NÍVEIS DE SERVIÇOS conforme subitem O prazo estabelecido pelo FISCAL REQUISITANTE na OS, para a conclusão dos serviços, deve ser rigorosamente cumprido, em caso contrário será computado para a aferição dos INDICADORES DE NÍVEIS DE SERVIÇO conforme subitem O GESTOR DO CONTRATO, após receber a OS com a indicação de ACEITO procederá à CONCLUSÃO da mesma que será computada para pagamento O GESTOR DO CONTRATO validará na OS a quantidade MAT conforme o PORTFÓLIO DE ATIVIDADES E ARTEFATOS O PORTFÓLIO DE ATIVIDADES E ARTEFATOS- ANEXO A contém: as atividades previstas para execução, conforme áreas definidas; os graus do FATOR DE PONDERAÇÃO FP previstos; os níveis do FATOR DE CONHECIMENTO INTERNO E MATURIDADE- FACIM previstos; a quantidade de MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT prevista para cada atividade em ralação aos graus do FP e ao FACIM; os ARTEFATOS previstos para a contratação; a TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS; a REQUISIÇÃO DE NOVA ATIVIDADE OU ARTEFATO, em anexo; 5.11 As atividades a serem demandadas, os artefatos a serem entregues e a quantidade de MAT para cada atividade deverão estar pré-definidos no PORTFÓLIO DE ATIVIDADES E ARTEFATOS para composição do custo de cada OS As atividades, os artefatos e a quantidade de MAT definidas no portfólio serão considerados como aceitos pela CONTRATADA no ato da assinatura do CONTRATO A inclusão de novas atividades ou artefatos ocorrerá sempre que o CONTRATANTE, por sugestão ou não da CONTRATADA, avaliar necessária e deverá ser integrada à lista referenciada no PORTFÓLIO DE ATIVIDADES E ARTEFATOS correspondente, quando atender os seguintes quesitos: solicitar por meio da REQUISIÇÃO DE NOVA ATIVIDADE OU ARTEFATO, conforme anexo no 54

55 PORTFÓLIO DE ATIVIDADES E ARTEFATOS; será indicada a área de atividade conforme TERMO DE REFERÊNCIA, numeração sequencial da atividade, nome identificador e objetivo da atividade; deverão ser classificadas pelos graus do FATOR DE PONDERAÇÃO estabelecidos, a quantidade de MAT prevista e os artefatos relacionados As novas atividades ou artefatos inclusos no PORTFÓLIO DE ATIVIDADES E ARTEFATOS obedecerão aos mesmos critérios de qualidade dos serviços e produtos, à quantidade mínima e máxima de glosas a ser aplicada para cada INS exigido na VERIFICAÇÃO DA QUALIDADE conforme previsto nos subitens e no subitem A inclusão de novas atividades ou artefatos será considerada validada após: assinatura de aprovação do FISCAL REQUISITANTE; assinatura de aprovação do FISCAL TÉCNICO; assinatura de autorização do GESTOR DO CONTRATO Após a validação prevista no subitem , será integrada como nova atividade ou artefato ao PORTFÓLIO DE ATIVIDADES E ARTEFATOS As atividades e artefatos, depois de inseridos no PORTFÓLIO DE ATIVIDADES E ARTEFATOS, não poderão ser excluídos em nenhuma hipótese, até a extinção do CONTRATO, podendo apenas ser desconsiderado para emissão das OS No caso de desconsideração de uma atividade pelo CONTRATANTE, o custo restante previsto para sua realização será redimensionado para outras atividades do PORTFÓLIO DE ATIVIDADES E ARTEFATOS independentemente dos tipos de atividades, mantendo a expectativa de consumo prevista contratualmente As novas atividades ou artefatos, após aprovação e assinatura de todas as partes, farão parte do contrato automaticamente, sem que haja necessidade de emissão de aditivos Para a execução das atividades a entrega de ARTEFATOS é OBRIGATÓRIA e considerada parte integrante dos serviços executados pela CONTRATADA Os artefatos previstos na contratação estão listados no PORTFÓLIO DE ATIVIDADES E ARTEFATOS conforme o subitem Todos os artefatos entregues ao Inep deverão ter registro da VERIFICAÇÃO DA QUALIDADE, por parte do FISCAL REQUISITANTE e FISCAL TÉCNICO do Inep, assegurando a conformidade dos padrões e requisitos exigidos pelo Inep, apoiados pela TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS Considera-se VERIFICAÇÃO DA QUALIDADE a análise dos artefatos recebidos em relação ao que for preconizado nos Guias, na METODOLOGIA DE GESTÃO E DESENVOLVIMENTO DE SISTEMAS- MGDS e demais padrões definidos pelo Inep Todos os artefatos concebidos durante a execução dos serviços devem ser rotineiramente sincronizados com o repositório eletrônico de documentos do Inep A CONTRATADA se obriga a manter consistentes e atualizados todos os artefatos produzidos e/ou alterados durante a execução dos serviços conforme forem sendo solicitados por meio de OS Para a execução dos serviços a CONTRATADA é OBRIGADA a observar a versão vigente dos Guias, da MGDS, da Política de Segurança da Informação e demais normas e padrões definidos pelo Inep, sendo obrigatório entregar os artefatos que estão sendo construídos e/ou alterados atualizados e em conformidade 55

56 com os mesmos A CONTRATADA é integralmente responsável pela manutenção de sigilo sobre quaisquer dados, informações, códigos-fonte, artefatos, contidos em quaisquer documentos e em quaisquer mídias, que venha a ter conhecimento durante a execução dos trabalhos, não podendo, sob qualquer pretexto e forma divulgar, reproduzir ou utilizar A TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS é referência para a avaliação dos artefatos entregues pela CONTRATADA A TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS possui três indicações que serão informadas pelo FISCAL REQUISITANTE e FISCAL TÉCNICO do Inep conforme execução das atividades solicitadas na OS, segue: A indicação de SIM significa que o(s) artefato(s) está de acordo com a descrição do item avaliado A indicação de NÃO significa que o(s) artefato(s) não está de acordo com a descrição do item avaliado A indicação de NÃO SE APLICA significa que o item avaliado não será considerado para a avaliação por motivos específicos da necessidade ou do artefato A indicação NÃO em qualquer dos itens da TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS implicará a indicação de NÃO ACEITO na OS sujeitando a CONTRATADA ao previsto nos subitens , , Os itens da TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS poderão sofrer alterações durante a execução do contrato, podendo ser excluídos os critérios vigentes ou incluídos novos critérios conforme as necessidades de negócio do Inep. TABELA 5- Tabela de Referência para Avaliação dos Artefatos Tabela de Referência para Avaliação dos Artefatos ITEM DESCRIÇÃO SIM NÃO NÃO SE APLICA 1 O conteúdo do artefato está em conformidade com os guias, metodologias e padrões estabelecidos pelo Inep. 2 A escrita no artefato está correta, redigido de forma clara, garantindo bom entendimento e evitando mais de uma interpretação em relação ao objetivo para o qual foi escrito. 3 O artefato produzido está adequadamente armazenado nas ferramentas de suporte à Engenharia de Software sem duplicidade de artefato ou 56

57 informação, sem conflito entre artefatos ou informações, sem repetição desnecessária de artefatos ou informações, no mesmo artefato ou entre outros artefatos. 4 O artefato segue estritamente a formatação definida com os principais responsáveis pelo artefato ou serviço precisamente identificados. 5 O artefato está relacionado ao serviço e atende ao solicitado na OS O CONTRATANTE poderá solicitar à CONTRATADA que construa, sem ônus para o Inep, modelos ou templates de artefatos que, após análise do FISCAL REQUISITANTE, FISCAL TÉCNICO e GESTOR DO CONTRATO, poderão ser adotados como padrão de formato dos documentos para a execução do serviço, sendo obrigatórios os seguintes pré-requisitos: o artefato deve estar previsto no PORTFÓLIO DE ATIVIDADES E ARTEFATOS; o artefato deve ser decorrente da necessidade de execução das atividades previstas no PORTFÓLIO DE ATIVIDADES E ARTEFATOS; seja gerada OS para execução de atividades que resultará na construção do artefato. 6 ELEMENTOS PARA GESTÃO DO CONTRATO 6.1 PAPÉIS E RESPONSABILIDADES O FISCAL REQUISITANTE do serviço será responsável por: Emitir mensalmente as ORDENS DE SERVIÇO contendo todas as tarefas e informações exigidas e encaminhá-las ao FISCAL TÉCNICO ou GESTOR DO CONTRATO, para avaliação Avaliar, quantificar e aprovar os serviços de assessoria tecnológica realizados pela CONTRATADA Supervisionar a execução e a qualidade dos ARTEFATOS objetos das ORDENS DE SERVIÇO Checar o RELATÓRIO DE EXECUÇÃO DE SERVIÇO encaminhado pela CONTRATADA Analisar a qualidade dos serviços realizados pela CONTRATADA O FISCAL TÉCNICO do contrato será responsável por: Acompanhar e fiscalizar a execução dos serviços e anotar em registro próprio todas as ocorrências relacionadas com a execução, sob os aspectos quantitativos e qualitativos, comunicando as ocorrências de quaisquer fatos que exijam medidas corretivas por parte da CONTRATADA ao GESTOR DO 57

58 CONTRATO; Supervisionar a execução e a qualidade dos ARTEFATOS objetos das ORDENS DE SERVIÇO Receber as ORDENS DE SERVIÇO do FISCAL REQUISITANTE, avaliar a compatibilidade contratual, registrar, autorizar a execução e encaminhar ao GESTOR DO CONTRATO para aprovação Encaminhar o RELATÓRIO DE EXECUÇÃO DE SERVIÇO, para cada ORDEM DE SERVIÇO finalizada, ao GESTOR DO CONTRATO O GESTOR DO CONTRATO será responsável por: Exigir da CONTRATADA, sempre que necessário, a apresentação de documentos que comprovem a validação e manutenção de todas as condições de habilitação e qualificação previstas no ato convocatório Atestar e encaminhar RELATÓRIO PARA PAGAMENTO- ANEXO F consolidado ao PREPOSTO para conhecimento e emissão da nota de cobrança até o 7º (sétimo) dia útil do mês subsequente Atestar a nota de cobrança encaminhada pela CONTRATADA e enviar, juntamente, com as ORDENS DE SERVIÇO e o RELATÓRIO PARA PAGAMENTO, à área administrativa para providências Registrar e autorizar a aplicação das glosas conforme previsto no TERMO DE REFERÊNCIA Encaminhar a documentação comprobatória de penalizações ou multas administrativas para os setores responsáveis e solicitar providências Proporcionar os espaços físicos, instalações, equipamentos e meios materiais necessários ao desempenho das atividades técnicas exigidas neste instrumento Promover a reunião de abertura do contrato com a presença dos fiscais do contrato do Inep, com o PREPOSTO e REPRESENTANTE LEGAL da CONTRATADA Promover reunião mensal com o PREPOSTO da CONTRATADA e com os ficais do contrato Emitir a Guia de Recolhimento da União (GRU) relativa ao uso dos ramais telefônicos disponibilizados aos recursos técnicos da CONTRATADA A Área Administrativa, além das obrigações normalmente imputadas legalmente, por meio do FISCAL ADMINISTRATIVO será responsável por: Permitir o acesso dos representantes e dos recursos técnicos da CONTRATADA ao local de prestação dos serviços, desde que devidamente identificados e respeitadas as normas que disciplinam a segurança do patrimônio, das pessoas e das informações; Proporcionar todas as condições necessárias para que a CONTRATADA possa cumprir o objeto desta contratação; Fiscalizar, com apoio da área técnica, o cumprimento, por parte da CONTRATADA, das exigências legais, tais como verificação das comprovações de regularidade fiscal e cumprimento das obrigações trabalhistas. 6.2 DEVERES E RESPONSABILIDADES DO CONTRATANTE São deveres e responsabilidades do CONTRATANTE: Permitir ao pessoal técnico da CONTRATADA, desde que identificado e incluído na relação de técnicos 58

59 autorizados, o acesso às dependências do Órgão, respeitadas as normas de segurança vigentes Fornecer, desde que haja disponibilidade, instalações físicas, ramais telefônicos, mobiliário e a infraestrutura tecnológica aos profissionais da CONTRATADA, quando a execução dos serviços desta contratação for realizada nas instalações do Inep, à exceção dos subitens descritos no subitem Notificar a CONTRATADA quanto a defeitos ou irregularidades verificados na execução dos serviços objeto da contratação, bem como quanto a qualquer ocorrência relativa ao comportamento de seus técnicos, quando em atendimento, que venha a ser considerado prejudicial ou inconveniente para o Inep Comunicar à CONTRATADA a necessidade de substituição de qualquer profissional que seja considerado inadequado para o exercício da função Efetuar os pagamentos devidos à CONTRATADA, na forma convencionada, dentro do prazo previsto, desde que atendidas às formalidades necessárias, após a aceitação dos serviços faturados Verificar a regularidade da situação fiscal e dos recolhimentos sociais trabalhistas da CONTRATADA, conforme determina a lei, antes de efetuar o pagamento devido Promover a fiscalização do contrato, sob os aspectos quantitativos e qualitativos, anotando em registro próprio as falhas detectadas e exigindo as medidas corretivas necessárias, bem como acompanhar o desenvolvimento do contrato, conferir os serviços executados e atestar os documentos fiscais pertinentes, podendo ainda sustar, recusar, mandar fazer ou desfazer qualquer procedimento que não esteja de acordo com os termos contratuais Comunicar tempestivamente à CONTRATADA as possíveis irregularidades detectadas na execução dos serviços Emitir, antes da execução de qualquer serviço, sua respectiva Ordem de Serviço (OS), com exceção dos casos emergenciais que terão prazo posterior de até 8(oito) horas úteis para registro da OS Homologar os serviços prestados de acordo com os requisitos preestabelecidos nas OS, atestando as respectivas faturas Fornecer à CONTRATADA, em tempo hábil, as informações necessárias e relevantes à consecução dos serviços a serem executados Especificar e estabelecer normas e diretrizes para a execução dos serviços ora contratados, definindo as prioridades, regras, bem como os prazos e etapas para cumprimento das obrigações Aplicar as penalidades previstas para o caso de não cumprimento de cláusulas contratuais ou aceitar as justificativas apresentadas pela CONTRATADA Comunicar, por escrito, à CONTRATADA, as modificações no ambiente computacional do Inep, e estipular prazos para adequação. 6.3 DEVERES E RESPONSABILIDADES DA CONTRATADA São deveres e responsabilidades da CONTRATADA: Designar um profissional de seu quadro para atuar como PREPOSTO nas dependências do Inep, com a responsabilidade pela gestão dos aspectos administrativos, legais e técnicos do contrato, relacionandose diretamente com o GESTOR DO CONTRATO, o FISCAL REQUISITANTE e com o FISCAL TÉCNICO fornecendo informações de controle e acompanhamento da execução dos serviços contratados, bem 59

60 como se responsabilizar pelo fiel cumprimento das OS. Caberá ao PREPOSTO: Coordenar as atividades necessárias ao atendimento das demandas, conforme acordos de níveis de serviço, primando pela qualidade dos serviços prestados e artefatos entregues Acusar recebimento da OS, indicando a data e horário de seu recebimento Distribuição das OS internamente à sua equipe técnica conforme área de ATIVIDADE solicitada Disponibilizar, nas instalações fornecidas pelo Inep, a seguinte infraestrutura para seus profissionais atuarem nos serviços desta contratação: Uma estação de trabalho completa para cada profissional alocado, com configuração de hardware e software adequada às necessidades dos serviços desta contração e compatível com o ambiente computacional do Inep Impressoras, com os respectivos suprimentos, em quantidades adequadas ao tamanho da equipe de profissionais e dimensionadas para atender à demanda necessária de impressão Softwares e licenças, necessários ao desempenho das atividades relacionadas aos serviços desta contratação (quando não for utilizado software gratuito), que deverão ser disponibilizados em conformidade com o padrão do ambiente computacional do Inep e em compatibilidade com as ferramentas utilizadas no Órgão Licenças de antivírus para cada estação de trabalho do mesmo fabricante e versão utilizada na rede corporativa de dados do Inep Providenciar, quando for necessário, equipe de suporte de hardware e software, capaz de manter a infraestrutura da CONTRATADA completamente operacional, de forma a garantir o desempenho satisfatório da equipe técnica alocada aos serviços desta contratação Com vistas a garantir confidencialidade, a integridade, a disponibilidade e a autenticidade das informações e dados, o Inep terá ampla liberdade para, sempre que for necessário, inspecionar e configurar os recursos de infraestrutura disponibilizados pela CONTRATADA Responsabilizar-se pelo pagamento das faturas dos ramais telefônicos disponibilizados aos seus profissionais alocados aos serviços desta contratação Será fornecido, desde que haja disponibilidade e mediante autorização do GESTOR DO CONTRATO, ao profissional alocado na contratação em questão à sua disposição um ramal e uma senha exclusiva para uso do mesmo A equipe de Telefonia do Inep, no início de cada mês, disponibilizará uma fatura por ramal na qual constarão as chamadas e respectivos valores deste ramal O GESTOR DO CONTRATO emitirá uma Guia de Recolhimento da União (GRU), que deverá ser paga pela CONTRATADA no prazo estipulado na GRU Selecionar, designar e manter em sua equipe profissionais cuja qualificação esteja em conformidade com os requisitos definidos. Os profissionais deverão ser contratados obrigatoriamente pelo regime da CLT, de forma a assegurar-se os benefícios trabalhistas Apresentar, para cada profissional alocado aos serviços desta contratação, os currículos e comprovantes de formação, de capacitação, de certificação e de experiência técnica,quando obrigatória, conforme previsto no subitem Capacitar a equipe técnica alocada aos serviços desta contratação sempre que se fizer necessário, considerando a evolução tecnológica ou mudança de tecnologia realizada pelo Inep em seu ambiente computacional. 60

61 6.3.7 Cumprir integralmente as especificações e prazos definidos na OS, garantindo a qualidade dos produtos e serviços entregues Solicitar autorização prévia do Inep antes de utilizar recursos de software que necessitem de aquisição de licença de uso, ou, antes de utilizar ferramentas cuja versão seja diferente daquelas previstas e em uso no Inep O Inep terá ampla liberdade de atualizar seu ambiente computacional, segundo sua necessidade e conveniência administrativa, cabendo, nestes casos, à CONTRATADA manter a compatibilidade, evoluindo e adaptando-se à respectiva mudança, às suas expensas, sem quaisquer custos adicionais para o Inep e dentro do prazo estipulado Garantir a execução dos serviços sem interrupção, substituindo, caso necessário, sem ônus para o Inep, qualquer técnico que tenha faltado ao serviço ou que esteja em gozo de férias, auxílio doença, auxílio maternidade ou qualquer outro benefício legal Cumprir as atividades inerentes ao CONTRATO com técnicos altamente especializados, assumindo total e exclusiva responsabilidade pelo cumprimento integral do objeto desta contratação Admitir, administrar, coordenar e avaliar, sob sua responsabilidade, os técnicos necessários à prestação dos serviços desta contratação, obrigando-se também por todos os tributos, impostos, encargos (trabalhistas ou não), incluindo toda e qualquer verba rescisória, além de todas as taxas que se apliquem ao seu ramo de atuação Apresentar, em conjunto com a fatura de serviços mensais, os comprovantes de regularidade da situação fiscal, conforme determina o inciso XIII do art. 55 da Lei nº 8.666/ Apresentar, em conjunto com a fatura de serviços mensais, os comprovantes previstos no artigo 36 da Instrução Normativa SLTI/MPOG nº 2 de Informar ao Inep, para efeito de controle de acesso às dependências do Órgão, o nome e o respectivo número da carteira de identidade dos empregados que farão parte da equipe técnica alocada aos serviços desta contratação, juntamente com o TERMO DE CREDENCIAMENTO- Anexo I e TERMO DE CIÊNCIA- Anexo L bem como informar, com antecedência mínima de 3 dias, as ocorrências de afastamento definitivo e as substituições em casos de falta, ausência legal ou férias Para os casos de desligamento a empresa deverá apresentar o TERMO DE DESCREDENCIAMENTO- Anexo J devidamente preenchido, bem como promover a devolução de crachás e outros materiais pertencentes ao Inep e que veio a ter acesso em virtude da contratação Todos os funcionários da empresa, que vierem a prestar serviço no Inep em virtude da presente contratação deverão circular nas dependências do Inep portando o crachá de identificação da empresa. O Inep apenas fornecerá o crachá de acesso Substituir qualquer um dos técnicos alocados aos serviços desta contratação, cuja atuação, permanência ou comportamento tenham sido julgados prejudiciais e inconvenientes à execução dos serviços ou às normas do Inep Prestar as informações e os esclarecimentos solicitados, no prazo máximo de 48 (quarenta e oito) horas úteis, a contar da solicitação feita pelo GESTOR DO CONTRATO Responder por quaisquer prejuízos que seus empregados ou PREPOSTO causarem ao Inep ou a terceiros, decorrentes de ação ou omissão culposa ou dolosa, procedendo imediatamente os reparos ou indenizações cabíveis e assumindo o ônus e a responsabilidade decorrente Aceitar, nas mesmas condições contratadas, os acréscimos ou supressões que se fizerem necessários, até o limite de 25% (vinte e cinco por cento) do valor atualizado do contrato Levar imediatamente ao conhecimento do GESTOR DO CONTRATO qualquer fato extraordinário ou 61

62 anormal que ocorrer na execução dos serviços contratados Responsabilizar-se sobre todos os atos de seus técnicos, relacionados ao manuseio de arquivos de dados, sistemas computadorizados, softwares e equipamentos de propriedade do Inep Não transferir a outrem, no todo ou em parte, o objeto da presente contratação Sob pena de RESCISÃO CONTRATUAL, não caucionar ou utilizar o contrato para qualquer operação financeira, sem prévia e expressa anuência do Inep Manter, durante vigência do contrato, as condições de habilitação e de qualificação exigidas no processo licitatório Ao término do contrato, seja por decurso de vigência ou por suspensão/cancelamento, promover a transição contratual com transferência de tecnologia e técnicas empregadas, sem perda de informações, capacitando, se solicitado, os técnicos do Inep ou da nova pessoa jurídica que continuará a execução dos serviços Todo conhecimento adquirido ou desenvolvido, bem como toda informação produzida e/ou utilizada para a execução dos serviços contratados, deverão ser disponibilizados ao CONTRATANTE ou empresa por ela designada até 30 (trinta) dias após a finalização do contrato Um PLANO DE TRANSIÇÃO, endereçando todas as atividades necessárias para a completa transição, deverá ser entregue ao CONTRATANTE pela CONTRATADA, até 03 (três) meses antes da expiração ou da finalização do CONTRATO No PLANO DE TRANSIÇÃO deverão estar identificados todos os compromissos, papéis e responsabilidades, artefatos e tarefas, a data de início da transição, o tempo necessário e a identificação de todos os envolvidos com a transição Será de inteira responsabilidade da CONTRATADA a execução do PLANO DE TRANSIÇÃO, bem como a garantia do repasse bem sucedido de todas as informações necessárias para a continuidade dos serviços pelo CONTRATANTE ou empresa por ele designada É de responsabilidade do CONTRATANTE, ou da empresa por ela designada, a disponibilidade dos recursos qualificados identificados no PLANO DE TRANSIÇÃO como receptores do serviço O fato de a CONTRATADA ou seus representantes não cooperarem ou reterem qualquer informação ou dado solicitado pelo CONTRATANTE, que venha a prejudicar, de alguma forma, o andamento da transição das tarefas e serviços para um novo prestador, constituirá quebra de CONTRATO, sujeitando-a as obrigações em relação a todos os danos causados ao CONTRATANTE, conforme estipulado nas sanções administrativas aplicáveis, conforme subitens e Durante o tempo requerido para desenvolver e executar o PLANO DE TRANSIÇÃO, a CONTRATADA deve responsabilizar-se pelo esforço adicional que necessite dedicar à tarefa de completar a transição, sem ônus para o CONTRATANTE Por esforço adicional entende-se o treinamento nas tarefas, pesquisas, transferência de conhecimento, entre a CONTRATADA e o CONTRATANTE e/ou empresa por ele designada, documentação ou qualquer outro esforço vinculado à tarefa de transição Efetuar a transferência de conhecimento para a equipe técnica do CONTRATANTE, de todos os novos serviços implantados ou modificados, mediante documentação técnica em repositório adotado pelo CONTRATANTE para esse fim. 6.4 METODOLOGIA DE AVALIAÇÃO DOS NÍVEIS DE SERVIÇO Para execução do contrato e atendimento das atividades demandadas, deverá a CONTRATADA 62

63 atender os seguintes níveis mínimos de serviço: Os INDICADORES DE NÍVEIS DE SERVIÇOS (INS) são um conjunto de critérios objetivos e mensuráveis estabelecidos entre o CONTRATANTE e a CONTRATADA com a finalidade de aferir e avaliar diversos indicadores relacionados com os serviços contratados, conforme tabelas apresentadas Nos INS estão definidos: a maneira pela qual estes fatores serão avaliados; o nível mínimo aceitável; e as glosas a serem aplicadas na quantidade de MAT faturadas MENSALMENTE quando o serviço prestado não alcançar o nível esperado A frequência de aferição e avaliação dos níveis de serviço será MENSAL, devendo o GESTOR DO CONTRATO, elaborar e registrar no RELATÓRIO PARA PAGAMENTO apresentado pela CONTRATADA, devolvendo-o à CONTRATADA até o 7º (sétimo) dia útil do mês subsequente ao da apresentação Constarão no RELATÓRIO PARA PAGAMENTO, dentre outras informações, os indicadores/metas de INS alcançados, recomendações técnicas, administrativas e gerenciais para o próximo período e demais informações relevantes para a gestão contratual, conforme descrito nos subitens Ficam estabelecidos os seguintes Indicadores de Níveis de Serviço- INS: INS1- Indicador de Nível de Serviço N 1. Execução das OS, ORDENS DE SERVIÇO DE GARANTIA- OSG e entrega dos artefatos no prazo solicitado. Para a aferição do indicador será utilizada a seguinte fórmula: Onde: INS1 = Indicador de Nível de Serviço 1 OSFP = Total de OS e OSG entregues fora do prazo no mês OS = Total de OS e OSG no mês Tabela 6-Tabela de verificação INS1 INS1 Glosas na Fatura Igual ou superior a 26% Multa+GLOSA de 5% De 21% a 25,99% 5% De 16% a 20,99% 4% De 11% a 15,99% 3% De 6% a 10,99% 2% De 1% a 5,99% 1% De 0% a 0,99% 0% INS2-Indicador de Nível de Serviço N 2. Quantidade de avaliações que obtiveram indicação de NÃO ACEITO na VERIFICAÇÃO DA QUALIDADE. 63

64 Para a aferição do indicador será utilizada a seguinte fórmula: Onde: INS2= Indicador de Nível de Serviço 2 AVNA= Total de avaliações com indicação NÃO ACEITO no mês AVM=Total de avaliações do mês Tabela 7-Tabela de verificação INS2 INS2 Glosas na Fatura Igual ou superior a 26% Multa+GLOSA de 5% De 21% a 25,99% 5% De 16% a 20,99% 4% De 11% a 15,99% 3% De 6% a 10,99% 2% De 1% a 5,99% 1% De 0% a 0,99% 0% INS3- Indicador de Nível de Serviço Nº3. Quantidade de ORDENS DE SERVIÇO DE GARANTIA- OSG geradas no mês. Para a aferição do indicador será utilizada a seguinte fórmula: Onde: INS3= Indicador de Nível de Serviço 3 TOSG= Total de OSG geradas no mês TOS= Total de OS geradas no mês Tabela 8-Tabela de verificação INS3 INS3 Glosas na Fatura Igual ou superior a 16% Multa+GLOSA de 5% De 11% a 15,99% 5% 64

65 De 6% a 10,99% 3% De 1% a 5,99% 1% De 0% a 0,99% 0% O melhor desempenho para todos os INS é 0%(zero por cento), garantindo os critérios de qualidade esperados e não incidindo glosas sobre a fatura mensal Os INDICADORES DE NÍVEIS DE SERVIÇOS estão agrupados em faixas de valores percentuais. Para cada uma dessas faixas há a previsão de um percentual de glosa sobre a fatura mensal. Na FAIXA MÁXIMA TOLERÁVEL para os valores dos INS o valor percentual da glosa que incidirá sobre a fatura mensal será de 5%. No caso do INS1 e INS2, a FAIXA MÁXIMA TOLERÁVEL (onde a glosa é de 5%) é delimitada pelos valores percentuais compreendidos no intervalo de 21% a 25,99%. Para o INS3 a FAIXA MÁXIMA TOLERÁVEL (onde a glosa é de 5%) é delimitada pelos valores compreendidos no intervalo de 11% a 15,99% As glosas por INS são CUMULATIVAS até o limite de 15% (quinze por cento) do total de MAT faturado no mês O valor máximo tolerável é de 25,99% (vinte e cinco vírgula noventa e nove por cento) para os INS1 e INS2, para o INS3 é de 15,99% (quinze vírgula noventa e nove por cento). Ultrapassando esses limites, além da glosa prevista, que será aplicada de acordo com o definido nas tabelas 6,7 e 8, será aplicada uma MULTA por DESCUMPRIMENTO DE ACORDO DE NÍVEIS DE SERVIÇO, conforme previsto no subitem É limitado à CONTRATADA atingir a FAIXA MÁXIMA TOLERÁVEL para até 1 (um) INS, superando-se este limite será aplicado, além das glosas previstas, uma MULTA por DESCUMPRIMENTO DE ACORDO DE NÍVEIS DE SERVIÇO, conforme previsto no subitem As glosas não são consideradas como SANÇÃO/PENALIDADE para a execução contratual, são mecanismos contratuais que buscam o equilíbrio entre o que se espera de qualidade nos serviços e o que é entregue pela CONTRATADA Para fins de cálculos serão considerados até dois dígitos após a vírgula decimal. 6.5 CONDIÇÕES DE PAGAMENTO Serão consideradas para o pagamento as Ordens de Serviço CONCLUÍDAS que obtiveram indicação de ACEITO pelo FISCAL REQUISITANTE até o dia 20 (vinte) de cada mês Será considerado como VOLUME MENSAL o cálculo do somatório das MAT, em unidades, das OS que obtiveram indicação de ACEITO pelo FISCAL REQUISITANTE Será considerado como VOLUME MENSAL DE GLOSAS, o total de MAT referentes ao cálculo do somatório das glosas previstas nos três INS em percentuais(%) O VOLUME MENSAL DE PAGAMENTO é a quantidade de MAT, em unidades líquidas a ser considerada para o pagamento e emissão da Nota Fiscal Para aferir o VOLUME MENSAL DE PAGAMENTO sua fórmula de cálculo será a seguinte: VMP=VM-VMG 65

66 Onde: VMP=Volume Mensal de Pagamento VM=Volume Mensal VMG= Volume Mensal de Glosas O VALOR DE PAGAMENTO é o valor em moeda nacional corrente, que fará jus à CONTRATADA, pela quantidade de MAT líquida acumulada no mês a ser considerada para o pagamento e emissão da Nota Fiscal Para aferir o VALOR DE PAGAMENTO sua fórmula de cálculo será a seguinte: VP =VMP X VALOR CONTRATADO DO MAT Onde: VP= Valor de Pagamento VMP=Volume Mensal de Pagamento Para fins de cálculos serão considerados até dois dígitos após a vírgula decimal O pagamento será efetuado mensalmente, de acordo com valor do serviço contratado, comprovados através relatórios mensais por meio do seguinte fluxo: A CONTRATADA entregará ao GESTOR DO CONTRATO, em até 5 (cinco) dias úteis no início de cada mês, um RELATÓRIO PARA PAGAMENTO numerado, contendo as seguintes informações: o total de Ordens de Serviço concluídas; o total de Ordens de Serviço de Garantia concluídas; o total de VERIFICAÇÃO DA QUALIDADE com a indicação de ACEITO ; o total de VERIFICAÇÃO DA QUALIDADE com a indicação de NÃO ACEITO ; o total de Ordens de Serviço concluídas fora do prazo; o total de Ordens de Serviço de Garantia concluídas fora do prazo; a quantidade total de MAT faturadas; uma lista contendo o Número, a Área de Atividade a e quantidade de MAT de cada Ordem de Serviço concluída Poderá ser solicitado à CONTRATADA que novas informações referentes à execução dos serviços sejam incluídas no RELATÓRIO PARA PAGAMENTO, desde que a CONTRATADA seja previamente informada por ofício até o dia 20 de cada mês O GESTOR DO CONTRATO homologará o RELATÓRIO PARA PAGAMENTO- Anexo F, registrando as glosas, as penalidades pertinentes, a quantidade de MAT aferida e o valor de pagamento em moeda corrente devolvendo-o por ofício em até 7 (sete) dias úteis, da data de recebimento, à CONTRATADA e solicitando a emissão da NOTA FISCAL A CONTRATADA terá prazo máximo de 3 (três) dias úteis, do recebimento do ofício, para apresentar 66

67 defesa, caso não concorde com algum termo no ofício, que será analisado pela Área Administrativa em até 7(sete) dias úteis, da data de recebimento A não apresentação da defesa, por parte da CONTRATADA, em relação ao RELATÓRIO PARA PAGAMENTO, encaminhado pelo Inep, dentro do prazo estipulado de 3 (três) dias úteis, implicará na plena aceitação dos termos, pela CONTRATADA A CONTRATADA terá prazo máximo de 3 (três) dias úteis, do recebimento do ofício, para emitir a NOTA FISCAL A efetivação do pagamento será mediante a apresentação das Notas Fiscais/Faturas correspondentes, acompanhadas do relatório citado no subitem , devidamente aceitas e atestadas pelo GESTOR DO CONTRATO, em conformidade com o discriminado neste TERMO DE REFERÊNCIA Deverá utilizar a unidade denominada como MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT para o dimensionamento do esforço de execução dos serviços, considerando o FATOR DE PONDERAÇÃO- FP subitem 3.1, o FATOR DE CONHECIMENTO INTERNO E MATURIDADE- FACIM subitem 3.2 e o resultado obtido conforme qualidade exigida para cada uma das atividades ou artefatos entregues conforme os INDICADORES DE NÍVEIS DE SERVIÇOS subitem Para a realização do pagamento, a CONTRATADA deverá atender às exigências do art. 36 da Instrução Normativa SLTI nº 2/2008, além de fazer constar da nota fiscal/fatura emitida, sem rasura, em letra legível, o nome do banco, o número da agência e da respectiva conta bancária. O pagamento será realizado em moeda corrente, mediante emissão de ordem bancária para crédito em conta da licitante vencedora, em até 10 dias após o aceite da nota fiscal/fatura O faturamento deverá ser mensal, mediante apresentação de nota de cobrança consolidada, determinando o total de MAT, aprovado pelo CONTRATANTE no RELATÓRIO PARA PAGAMENTO- Anexo F, e já descontadas as glosas aplicadas em função do não atendimento dos indicadores de níveis de serviços previstos no Anexo E, os exigidos contratualmente e os descontos previstos, calculados conforme subitem No caso de discordância das glosas aplicadas pelo GESTOR DO CONTRATO, por não atendimento aos níveis de serviços conforme subitem 6.4, a CONTRATADA deverá apresentar o recurso administrativo e emitir a NOTA FISCAL conforme a totalização estipulada no RELATÓRIO PARA PAGAMENTO- Anexo F Se a decisão da Administração for favorável ao recurso da CONTRATADA a mesma emitirá a NOTA FISCAL de cobrança adicional para que seja efetuado o pagamento referente ao custo glosado A NOTA FISCAL de cobrança adicional emitida pela CONTRATADA deverá ser atestada pelo GESTOR DO CONTRATO e encaminhada para a área financeira efetuar o pagamento, acompanhada do RELATÓRIO PARA PAGAMENTO- Anexo F, o recurso apresentado pela CONTRATADA, e um memorando com o parecer final do GESTOR DO CONTRATO O RELATÓRIO PARA PAGAMENTO- Anexo F deverá especificar o custo aprovado para cada ORDEM DE SERVIÇO e o realmente autorizado, devidamente preenchido e assinado pelo GESTOR DO CONTRATO Em quaisquer casos de aplicação de glosas, deverão ser anexados os documentos e relatórios comprobatórios do não atendimento dos resultados ou níveis de qualidade exigidos As glosas previstas para não atendimento dos INDICADORES DE NÍVEIS DE SERVIÇOS, definidos no Anexo E, serão aplicadas pelo GESTOR DO CONTRATO, independentemente das demais penalidades previstas contratualmente. 67

68 6.6 GARANTIA A CONTRATADA deverá garantir os serviços pelo período de 1 (um) ano, a partir da indicação de ACEITO na OS, pelo FISCAL REQUISITANTE Caberá à CONTRATADA, no período de garantia, sem ônus para o Inep, realizar toda a correção decorrente de erros ou falhas cometidas na execução dos serviços contratados e/ou decorrentes de integração e adequação sistêmica, desde que, comprovadamente, não tenham se dado em função de falhas nas especificações ou descrição das necessidades feitas pelo Inep Estão cobertos pela garantia todos os serviços executados, bem como todos os artefatos relacionados Será emitida ORDEM DE SERVIÇO DE GARANTIA (OSG) para os itens em garantia, a(s) qual(ais) se aplicará(ão) os mesmos critérios de execução, verificação de qualidade e garantia prevista para as OS, além de serem consideradas para a aferição dos INDICADORES DE NÍVEL DE SERVIÇOS (INS), da CONTRATADA, conforme subitem Quando do encerramento da vigência do contrato de prestação de serviços, a licitante vencedora deverá assinar CONTRATO DE GARANTIA TÉCNICA, com vigência de 12 meses a partir da data de indicação de ACEITO na ultima OS concluída pela vigência do contrato de prestação de serviço. 6.7 SIGILO E RESPONSABILIDADE A CONTRATADA deverá manter sigilo, sob pena de responsabilidades civis, penais e administrativas, sobre todo e qualquer assunto de interesse do CONTRATANTE ou de terceiros de que tomar conhecimento em razão da execução do objeto deste Contrato devendo orientar seus empregados nesse sentido A CONTRATADA, quando da assinatura do contrato, por meio de seu representante assinará o TERMO DE COMPROMISSO- Anexo N em que se responsabilizará pela manutenção de sigilo e confidencialidade das informações a que possa ter acesso em decorrência da contratação A CONTRATADA fica sujeita à sanção prevista no subitem em caso de descumprimento do TERMO DE COMPROMISSO A CONTRATADA deverá apresentar para cada funcionário que vier a executar atividades referentes ao objeto da contratação, o TERMO DE CIÊNCIA- Anexo L, em que seus profissionais declaram estar cientes das responsabilidades pela manutenção de sigilo e confidencialidade. 6.8 MECANISMOS FORMAIS DE COMUNICAÇÃO No ato da assinatura do contrato, a CONTRATADA deverá indicar um profissional de seu quadro para atuar, no ambiente do Inep, como PREPOSTO. Esse profissional estará responsável pela gestão dos aspectos técnicos, administrativos e legais do contrato, relacionando-se diretamente com o GESTOR DO CONTRATO, o FISCAL TÉCNICO e o FISCAL REQUISITANTE Toda execução dos serviços deverá ser administrada pelo PREPOSTO Imediatamente após a assinatura do contrato, o GESTOR DO CONTRATO no Inep convocará o REPRESENTANTE LEGAL juntamente com o PREPOSTO da CONTRATADA para a reunião inicial, na qual serão tratados os seguintes assuntos: assinatura do TERMO DE COMPROMISSO- Anexo N; 68

69 esclarecimentos sobre a forma de comunicação a ser adotada entre o Órgão e a CONTRATADA; entrega dos documentos que compõem os padrões em uso no Inep, a saber: apresentação dos tipos de ORDENS DE SERVIÇO que serão utilizadas na passagem de demandas do Inep para a CONTRATADA e esclarecimentos sobre o seu preenchimento; esclarecimentos acerca dos INDICADORES DE NÍVEIS DE SERVIÇOS previstos no TERMO DE REFERÊNCIA, bem como sobre o período de adaptação e ajustes da CONTRATADA ao contrato; esclarecimentos relacionados ao funcionamento do Órgão, tais como: horário de trabalho, local disponível para a equipe da CONTRATADA, regimento interno do Órgão, forma de acesso dos colaboradores da CONTRATADA às dependências do Inep e demais informações pertinentes; data de início das atividades do contrato; demais assuntos relevantes para o início do contrato pela CONTRATADA Essa reunião será registrada em ata, documento que deverá ser assinado por todos os presentes e que passará a integrar o contrato Toda a comunicação relacionada aos aspectos administrativos e legais do contrato será formalizada via ofício e encaminhada ao PREPOSTO designado pela CONTRATADA Caberá ao PREPOSTO fornecer informações de controle e acompanhamento da execução dos serviços contratados, bem como responsabilizar-se pelo fiel cumprimento das ordens de serviço O PREPOSTO deverá coordenar as atividades necessárias ao atendimento das demandas, conforme indicadores de níveis de serviço, primando pela qualidade dos serviços prestados e artefatos entregues Todas as ORDENS DE SERVIÇO emitidas pela DTDIE serão unicamente e exclusivamente dirigidas ao PREPOSTO, que deverá acusar recebimento da OS, indicando a data e horário de seu recebimento Compete ao PREPOSTO a distribuição das ORDENS DE SERVIÇO internamente à sua equipe técnica conforme área de ATIVIDADE solicitada A CONTRATADA deverá manter o PREPOSTO, nas dependências do Inep, de segunda a sexta-feira no horário de 08h00min as 18h00min para executar a coordenação dos serviços, não excluída a possibilidade de atendimentos aos fins de semanas, feriados ou em horários noturnos desde que previamente comunicado e sem nenhum ônus adicional ao Inep As interações dos profissionais da CONTRATADA com os usuários e profissionais do Inep, para fins de execução dos serviços, ocorrerão nas instalações do Inep, cabendo à CONTRATADA a responsabilidade pelo deslocamento dos profissionais envolvidos até o local de prestação de serviços. 7 ESTIMATIVA DE PREÇO Foi realizada uma pesquisa de preços em empresas que atuam no mercado, buscando obter-se o valor médio cobrado por MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT. Tal pesquisa foi realizada a partir do envio de FAX de documento com 13 páginas, com informações necessárias para a estimativa de cotação do preço. Foi solicitado a cada fornecedor que, com base no material encaminhado, fizesse uma proposta de preços por MAT, considerando a prestação dos serviços nas dependências do Inep. 69

70 Foram convidados 10 (DEZ) fornecedores, porém somente 5 empresas encaminharam suas propostas de preços, tendo sido obtido o valor médio de R$ 175,20 (CENTO E SETENTA E CINCO REAIS E VINTE CENTAVOS) por MAT. Com base no preço médio obtido e na quantidade de MAT a ser contratada, temos o valor estimado de R$ ,00 (SETE MILHÕES E OITO MIL REAIS) anuais. 8 ADEQUAÇÃO ORÇAMENTÁRIA FONTE DE RECURSOS Programa: 2109 Ação: 20RH Valor: R$ (SETE MILHÕES E OITO MIL REAIS) 9 SANÇÕES E PENALIDADES A CONTRATADA ficará sujeita, com fundamento nos artigos 86 e 87 da Lei n /1993, no caso de atraso injustificado, assim considerado pela Administração, de execução parcial ou inexecução da obrigação, sem prejuízo das responsabilidades civil e criminal, assegurada prévia e ampla defesa, às seguintes penalidades: 9.1 Advertência: Colaborador da CONTRATADA, transitar internamente nas instalações do Inep sem estar devidamente identificado com o respectivo crachá; Colaborador da CONTRATADA, tratar de maneira agressiva, sem cordialidade e desrespeitosa os servidores e demais prestadores de serviços do Inep; Não responder às notificações no prazo determinado, conforme subitem 9.4; Não apresentar documentação exigida, no prazo requerido, tanto da CONTRATADA como dos profissionais, para fazer cumprir os trâmites administrativos do contrato. 9.2 Multa de: % (dois por cento) sobre o VALOR DE PAGAMENTO, no caso de acumular 3 (três) advertências durante a execução do contrato; % (dois por cento) sobre o VALOR DE PAGAMENTO, no caso de permitir que profissional sem a qualificação exigida execute os serviços contratados; % (cinco por cento) sobre o VALOR DE PAGAMENTO, no caso de agir de maneira ou com recursos antiéticos dolosamente, buscando obter vantagens administrativas e/ou financeiras na execução do contrato; % (cinco por cento) sobre o VALOR DE PAGAMENTO, no caso de obter valor superior ao VALOR MÁXIMO TOLERÁVEL, conforme subitem 6.4.9, em quaisquer INDICADORES DE NÍVEIS DE SERVIÇO, sem prejuízo das GLOSAS previstas; % (cinco por cento) sobre o VALOR DE PAGAMENTO, no caso de atingir a FAIXA MÁXIMA TOLERÁVEL, conforme subitem , em mais de 1(um) INDICADOR DE NÍVEIS DE SERVIÇO, sem 70

71 prejuízo das GLOSAS previstas; % (dois por cento) sobre o valor contratado, no caso de inobservância ao estabelecido no TERMO DE COMPROMISSO; ,2% (zero vírgula dois por cento) por dia de atraso sobre o VALOR DE PAGAMENTO, no caso de descumprimento das obrigações contratuais assumidas, contando a partir de encerrado o prazo de resposta conforme subitem 9.4, até o 30º (trigésimo) dia, sem prejuízo das demais penalidades; ,4% (zero vírgula quatro por cento) por dia de atraso sobre o VALOR DE PAGAMENTO, no de descumprimento das obrigações contratuais assumidas após o 30º (trigésimo) dia, limitada ao percentual de 10% (dez por cento), sem prejuízo das demais penalidades. 9.3 Será caracterizada a INEXECUÇÃO TOTAL DO CONTRATO quando, no período de um ano, durante a execução contratual, a CONTRATADA acumular 4 (quatro) MULTAS, sujeitando-a ainda à: Multa de 10% (dez por cento) sobre o valor contratado; Suspensão temporária de participação em licitação e impedimento de contratar com a Administração, por prazo não superior a 2 (dois) anos Declaração de inidoneidade para licitar ou contratar com a Administração Pública enquanto perdurarem os motivos determinantes da punição ou até que seja promovida a reabilitação perante a própria autoridade que aplicou a penalidade, que será concedida sempre que o contratado ressarcir a Administração pelos prejuízos resultantes e após decorrido o prazo da sanção aplicada com base no inciso anterior. 9.4 A CONTRATADA deverá responder às notificações previstas em, no máximo, 48 (quarenta e oito) horas úteis. 9.5 A contagem das advertências será ZERADA a cada acumulo de 3 (três) advertências procedendo para aplicação de multa conforme subitem Mensalmente será verificado se houve alguma incidência da CONTRATADA nos referidos itens de SANÇÕES E PENALIDADES. 9.7 Será aplica uma única multa sobre o VALOR DE PAGAMENTO, com a soma dos percentuais para cada ocorrência correspondente ao mês verificado. 9.8 Os primeiros noventa dias após a emissão da primeira OS serão considerados como período de adaptação e ajustes, no qual não incidirá MULTA ou SANÇÃO, prevalecendo os demais elementos de faturamento. Nesse período, as multas ou sansões serão calculados para fins de histórico, porém não incidirão penalidades No período de adaptação, se houverem OS entregues fora do prazo estipulado para execução, ou caso a contratada se recuse a atender alguma OS, o período de adaptação será interrompido passando a incidir as penalidades previstas neste Termo de Referência Em se tratando de renovação do contrato não caberá o período de adaptação e ajustes, incidindo MULTAS e SANSÕES previstos a partir da renovação contratual. 9.9 As glosas previstas no subitem 6.4 não serão consideradas como SANÇÕES E PENALIDADES para a execução contratual, sendo passíveis de aplicação a partir do primeiro mês de prestação. 71

72 10 CRITÉRIOS DE SELEÇÃO DO FORNECEDOR 10.1 PROPOSTA TÉCNICA A proposta deverá ser apresentada contendo no mínimo: Especificação clara e completa do objeto oferecido, obedecida preferencialmente a mesma ordem constante no TERMO DE REFERÊNCIA, devendo conter o detalhamento de todas as características dos serviços ofertados, assim como a especificação da garantia dos serviços e dos prazos de execução PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS que contenha as especificações detalhadas dos serviços, conforme modelo presente no Anexo O, em moeda corrente nacional, expresso em algarismos e por extenso nos valores unitários e totais dos serviços, ofertados Prazo de validade mínima da proposta que deverá ser de 60 (sessenta) dias, a contar da data de sua apresentação Declaração expressa de que os preços contidos na proposta incluem todos os custos, despesas e encargos A razão social, o CNPJ, colocando o número do Edital do Pregão, dia e hora de abertura, endereço completo, o número do telefone, fax e , bem como, o número de sua conta corrente, o nome do Banco e a respectiva Agência onde deseja receber seus créditos, não sendo fator de desclassificação o descumprimento deste item Apresentar quaisquer outras informações afins que julgar necessárias ou convenientes, não sendo fator de desclassificação o descumprimento deste item As empresas licitantes deverão apresentar, juntamente com a Proposta de Preços, o TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA- Anexo M devidamente preenchido e assinado por responsável da DTDIE, afirmando que a licitante visitou as dependências do Inep, onde serão prestados os serviços, tomando conhecimento de todos os aspectos que possam influir direta ou indiretamente na execução dos mesmos As empresas licitantes deverão apresentar, juntamente com a Proposta de Preços, o QUADRO DE RECURSOS TÉCNICOS - Anexo Q, devidamente preenchido e assinado, composto dos quantitativos de recursos técnicos que pretende utilizar in loco, distribuídos por áreas de atuação previstas para este TERMO DE REFERÊNCIA, e respectivas remunerações mensais de cada grupo Todos os requisitos técnicos deverão ser indicados na documentação técnica (incluindo número da página e sua respectiva fonte) A apresentação da proposta implicará em PLENA ACEITAÇÃO, por parte do proponente, das condições estabelecidas QUALIFICAÇÃO TÉCNICA Requisito de Capacidade Técnica As empresas licitantes deverão apresentar ATESTADO(S) DE CAPACIDADE TÉCNICA, fornecido(s) por pessoa jurídica de direito público ou privado comprovando a experiência na execução de serviços de ASSESSORIA TECNOLÓGICA EM SISTEMAS DE INFORMAÇÃO totalizando, no mínimo, (dez mil) Horas de serviços de Análise de Arquitetura de Sistemas, e/ou Análise de Negócio para Sistemas. No caso de atestados emitidos por empresa da iniciativa privada, não serão considerados aqueles 72

73 emitidos por empresa pertencente ao mesmo grupo empresarial da licitante, sua subsidiária, controlada, controladora ou consórcio e por empresa na qual haja pelo menos uma mesma pessoa física ou jurídica que seja sócio da empresa emitente e da licitante Requisitos de Qualificação das Equipes Técnicas Os profissionais a serem envolvidos nos serviços objeto deste TERMO DE REFERÊNCIA, deverão estar capacitados nos recursos que compõem o ambiente computacional do Inep, descrito no QUADRO DE RECURSOS DE TI- Anexo G e possuir a qualificação mínima exigida nos PERFIS PROFISSIONAIS E FORMAÇÃO EXIGIDA- Anexo P Deverá comprovar que os profissionais que pretende utilizar in loco para execução dos serviços apresentam a qualificação mínima e a experiência exigida Para cada profissional alocado, a CONTRATADA deverá entregar o currículo e os comprovantes de formação, de capacitação, de certificação técnica e de experiência do profissional Serão considerados como comprovantes cópias acompanhadas dos respectivos originais: de diplomas; de certificados; de registros em carteira de trabalho; de contratos de trabalho assinados, de declarações ou atestado(s) fornecido(s) por pessoa jurídica de direito público ou privado comprovando a experiência No ato da entrega dos documentos o CONTRATANTE validará as cópias conforme os originais devolvendo-os logo em seguida. As cópias com autenticação em Cartório serão dispensadas da validação, não sendo obrigado apresentar os originais A CONTRATADA compromete-se a alocar, em todos os serviços contratados pela DTDIE, profissionais com perfis e qualificações adequados, mantendo ao longo da vigência do contrato todas as condições que apresentaram em sua habilitação e qualificação no processo licitatório A CONTRATADA, com o objetivo de melhorar a qualidade dos produtos ou dos serviços prestados, poderá solicitar ao CONTRATANTE que outros perfis profissionais atuem no Inep, desde que o perfil tenha relação com o objeto do contrato e haja vínculo empregatício entre o profissional e a CONTRATADA sendo obrigado aos subitens , e A atuação de outro perfil profissional fica condicionada ao deferimento do GESTOR DO CONTRATO e dos FISCAIS DO CONTRATO, que poderão deferir ou não a autorização conforme o caso Para execução das atividades de ANÁLISE DE ARQUITETURA DE SISTEMAS é exigido que o profissional tenha: Análise de Arquitetura para Soluções JAVA: Formação de nível superior na área de informática, reconhecido pelo Ministério da Educação, ou formação de nível superior em qualquer área com curso de pós-graduação lato sensu (especialização) na área de informática; (cinco) anos em atividades de desenvolvimento de sistemas de informação; (três) anos em Arquitetura de Sistemas; Comprovar experiência de no mínimo 02 (dois) anos em projetos de integração de sistemas; Comprovar experiência de no mínimo 02 (dois) anos em Jboss Seam; Comprovar experiência de no mínimo 02 (dois) anos em Java, J2EE e WebService; Comprovar experiência de no mínimo 02 (dois) anos em Hibernate, Java Server Faces, Rich Faces, 73

74 Facelets; Comprovar experiência de no mínimo 02 (dois) anos em JBoss AS; Certificação em Sun Certified Java Programmer-SCJP; Certificação em Sun Certified Web Component Developer-SCWCD Análise de Arquitetura para Soluções PHP: Formação de nível superior na área de informática, reconhecido pelo Ministério da Educação, ou formação de nível superior em qualquer área com curso de pós-graduação lato sensu (especialização) na área de informática (cinco) anos em atividades de desenvolvimento de sistemas de informação; (três) anos em Arquitetura de Sistemas; Comprovar experiência de no mínimo 02 (dois) anos em projetos de integração de sistemas; Certificação em Zend Framework Certification emitido pela Zend; Comprovar experiência de no mínimo 04 (quatro) anos em PHP; Comprovar experiência de no mínimo 02 (dois) anos em JQuery; Comprovar experiência de no mínimo 02 (dois) anos em Ajax; Comprovar experiência de no mínimo 02 (dois) anos em Json; Comprovar experiência de no mínimo 02 (dois) anos em UML; Comprovar experiência de no mínimo 02 (dois) anos em Oracle ou PostgreSQL ou Microsoft SQL Server ou alguma das seguintes certificações: Microsoft Certified IT Professional (MCITP); Oracle PL/SQL Developer Certified Associate; Comprovar experiência de no mínimo 02 (dois) anos em Metodologia Ágil ou RUP ou alguma das seguintes certificações: Scrum Alliance - Scrum Certification (CSM); IBM Certified Solution Designer - IBM Rational Unified Process Para execução das atividades de ANÁLISE DE NEGÓCIO PARA SISTEMAS é exigido que o profissional tenha: Formação de nível superior na área de informática, reconhecido pelo Ministério da Educação, ou formação de nível superior em qualquer área com curso de pós-graduação lato sensu (especialização) na área de informática; Experiência de, no mínimo, 07 (sete) anos em TI; Experiência de, no mínimo, 03 (três) anos nas funções de análise de negócio; Experiência de, no mínimo, 01(um) ano de atividades em projetos com metodologias ágeis; Certificação PMP- Project Management Professional, concedida pela PMI-Project Management 74

75 Institute; Certificação CSM- Certified Scrum Master e CSPO- Certified Scrum Product Owner, Scrum Aliance ou PSM I-Professional Scrum Master I, Scrum. Org sendo aceito também em substituição CSP- Certified Scrum Profesional, Scrum Aliance ou PSM II- Professional Scrum Master II, Scrum. Org Curso, com mínimo de 40 horas, em: Processo Unificado; ITIL V3- Information Technology Infrastructure Library; COBIT- Control Objectives for Information and related Technology; BPM- Business Process Management; UML- Unified Modeling Language; Para o PREPOSTO da CONTRATADA é exigido que o profissional tenha: Formação de nível superior completo, reconhecido pelo Ministério da Educação; Experiência mínima de 01 (um) ano com gestão de contratos e de projetos na Administração Pública ou Privada; Certificação CSM (Certified Scrum Master), concedida por profissional credenciado pela Scrum Alliance; Certificação PMP concedida pelo PMI A CONTRATADA terá prazo de 40( quarenta) dias corridos, do início oficial da prestação dos serviços, para apresentar as documentações comprobatórias de qualificação das equipes técnicas in loco. Após este prazo a CONTRATADA deverá apresentar para cada novo profissional alocado, o currículo e os comprovantes de formação, de capacitação, de certificação técnica e de experiência do profissional conforme subitem , além do previsto nos subitens e Critérios de Seleção O julgamento das propostas de preços será pelo critério do MENOR PREÇO GLOBAL, sendo declarada vencedora a licitante que fornecer menor preço global para o total de unidades da Métrica para Assessoria Tecnológica- MAT previstas e atender aos critérios de habilitação previstos no subitem De acordo com o Art.6º da Instrução Normativa Nº 04 de 12 de novembro de 2010/ SLTI-MP, conforme segue: Art. 6º Nos casos em que a avaliação, mensuração ou fiscalização da Solução de Tecnologia da Informação seja objeto de contratação, a contratada que provê a Solução de Tecnologia da Informação não poderá ser a mesma que a avalia, mensura ou fiscaliza, e por entender que diversas atividades previstas no PORTFÓLIO DE ATIVIDADES E ARTEFATOS- Anexo A, possuem características ou funções de fiscalização e supervisão, ficam impedidas de participar, direta ou indiretamente, do certame empresas que possuem contratos de prestação de serviços ou fornecimento de recursos de Tecnologia da Informação em vigência com o Inep Considera-se participação indireta, para fins do disposto neste Termo de Referência, a existência de qualquer vínculo de natureza técnica, comercial, econômica, financeira ou trabalhista entre empresas que possuem contratos de prestação de serviços ou fornecimento de recursos de Tecnologia da Informação em vigência com o Inep e o licitante no certame O procedimento licitatório obedecerá a Lei nº , de 7 de julho de 2002; Decreto nº , de 08 de 75

76 agosto de 2000, alterados pelos Decretos nos 3.693, de 20 de dezembro de 2000 e 3.784, de 06 de abril de 2001; Decreto nº de 31 de maio de 2005; Decreto nº , de 07 de julho de 1997; Instrução Normativa nº. 02, de 30 de abril de 2008; Instrução Normativa nº. 04, de 12 de novembro de 2010; e demais legislações correlatas, aplicando-se subsidiariamente, no que couber, a Lei nº , de 21 de junho de 1993, com suas alterações subsequentes Critérios de Habilitação Será considerada habilitada, além das exigências administrativas e legais especificadas no Edital, a empresa que apresentar: TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA- Anexo M, assinado pela equipe técnica da DTDIE do Inep, declarando ter conhecimento da plataforma atualmente instalada, locais de realização dos serviços, instalações de infraestrutura, condições ambientais e locais para acomodação da equipe CONTRATADA; A vistoria técnica deverá ocorrer por horário marcado, e será agendada pela DTDIE através do telefone (61) ; O agendamento de vistoria poderá ocorrer até 48 (quarenta e oito) horas antes da data e horário de abertura do processo licitatório; A vistoria técnica deverá ser realizada em até 24 (vinte e quatro) horas antes da abertura do processo licitatório ATESTADO(S) DE CAPACIDADE TÉCNICA, fornecido(s) por pessoa jurídica de direito público ou privado comprovando a experiência na execução de serviços de ASSESSORIA TECNOLÓGICA EM SISTEMAS DE INFORMAÇÃO E PROCESSOS totalizando, no mínimo, (dez mil) horas de serviços de Análise de Arquitetura de Sistemas, e/ou Análise de Negócio para Sistemas Os ATESTADO(S) DE CAPACIDADE TÉCNICA, com a discriminação do nome de cada órgão/empresa emitente, comprovando a efetiva execução dos serviços e informações prestadas pela licitante e elaborados em papel timbrado da empresa emitente, contendo os seguintes dados mínimos e obrigatórios: - Razão Social, CNPJ e Endereço Completo da Empresa Emitente; - Razão Social da Licitante; - Referência do Contrato; ; - Vigência do Contrato: De / / a / / ; - Objeto do Contrato; - Descrição do Objeto do Contrato (descrição detalhada dos serviços prestados); - Local e Data de Emissão do Atestado; - Nome e Assinatura do Signatário, Cargo, Telefone para contato e Fax. -Descrição detalhada de todo o serviço prestado; - Total de horas prestadas Apresentar o QUADRO DE RECURSOS TÉCNICOS - Anexo Q, devidamente preenchido, composto dos quantitativos de recursos técnicos que pretende utilizar in loco, distribuídos por áreas de atuação previstas para este TERMO DE REFERÊNCIA, e respectivas remunerações mensais de cada grupo Apresentar a PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS- Anexo O, devidamente preenchida para cada área de atuação ou especialização prevista para este TERMO DE REFERÊNCIA, 76

77 separadas por faixas de remuneração, e o quadro resumo final Na planilha de resumo final, os campos de Despesas Administrativas e Margem de Lucro deverão conter percentuais ou valores superiores a zero. A cotação de percentuais irrisórios ou iguais a zero deverão ser previamente justificada pelas licitantes, cabendo à equipe de apoio do pregoeiro analisar a pertinência da justificativa É facultada a substituição das planilhas acima pelo modelo para composição de custos definido na Instrução Normativa MPOG nº 02/2008, alterada pela Portaria nº 7 de 09 de março de 2011, devidamente preenchida CRITÉRIO TÉCNICO OBRIGATÓRIO - A empresa deverá apresentar termo de conhecimento das atividades relacionadas nos anexos e demais condições vistoriadas, declarando ter capacitação técnica para atender a todos os requisitos especificados no Edital CRITÉRIO DE ACEITABILIDADE DE PREÇOS - Os preços propostos deverão ser especificados em moeda nacional, sendo considerada vencedora a que apresentar menor preço global para a quantidade total de MAT especificadas no presente TERMO DE REFERÊNCIA CRITÉRIOS DE JULGAMENTO - Além das exigências administrativas e legais especificadas no Edital, as concorrentes deverão obrigatoriamente apresentar os itens acima relacionados A não apresentação de quaisquer dos documentos acima relacionados implicará na desclassificação da licitante; Desclassificação da licitante que apresentar o QUADRO DE RECURSOS TÉCNICOS Anexo Q que não contemplem os perfis ou quaisquer das áreas de atuação previstas para este TERMO DE REFERÊNCIA Desclassificação da licitante que apresentar Composição de custos inferiores ou iguais a zero para os campos Despesas Administrativas e Margem de Lucro Desclassificação da licitante que apresentar a composição de custos irrisórios ou iguais a zero para os campos Despesas Administrativas e Margem de Lucro, sem a apresentação de justificativa ou com esclarecimentos não considerados plausíveis pela Administração Desclassificação da licitante que apresentar percentuais para os campos Encargos Sociais e Impostos em desacordo com a legislação vigente Serão consideradas propostas com indícios de inexequibilidade aquelas cujo valor unitário apresentado por MÉTRICA PARA ASSESSORIA TECNOLÓGICA- MAT seja inferior a 70% do menor entre os seguintes valores: I - Preço orçado pelo Inep; II - Média aritmética dos valores das propostas superiores a 50% do preço orçado pelo Inep Caso a proposta de menor preço apresente indício de inexequibilidade de acordo com o critério acima, será facultado à licitante comprovar a exequibilidade de sua proposta. Após análise da comprovação oferecida, e permanecendo dúvidas quanto à exequibilidade da proposta, o Inep poderá promover diligência para aferir a legalidade e exequibilidade da proposta, conforme previsto no 3º do art. 29 da Instrução Normativa MP nº 2 de 30 de abril de Caso a licitante não apresente a comprovação de exequibilidade, ou o resultado da diligência indique incapacidade de execução, a proposta correspondente será desclassificada do certame Por se tratar de certame do tipo pregão, o critério de desempate adotado será o que apresentar menor preço global A critério da Administração poderá ser necessário diligenciar a pessoa jurídica indicada no 77

78 ATESTADO(S) DE CAPACIDADE TÉCNICA, visando obter informações sobre o serviço prestado A critério da Administração e quando assim entender necessário, antes de emitir o parecer de desclassificação previsto nos subitens a , poderá ser solicitado novos esclarecimentos complementares e por escrito da licitante que possibilite fundamentar a desclassificação ou aceitabilidade das informações encaminhadas nas planilhas de custos É vedada a participação de empresas em consórcio O(s) ATESTADO(S) DE CAPACIDADE TÉCNICA, documentações e comprovações necessárias para que a administração certifique a veracidade das informações deverão conferir com o CNPJ e razão social da empresa licitante Requisitos Obrigatórios Comprovar, no momento de habilitação, ter atendido aos requisitos de habilitação exigidos, conforme subitem 10.4; Estar legalmente habilitada e autorizada pelas Organizações Federais, Estaduais e Municipais para exercer as atividades exigidas pelo Edital; Designar um representante legal, que será a interface de contato técnico entre o CONTRATANTE e a licitante para realizar a VISTORIA TÉCNICA. O representante legal da licitante deverá garantir todo o sigilo e reserva das informações internas da Organização O representante legal da licitante deverá portar original ou cópia autenticada do contrato social da empresa e seus documentos pessoais originais de identificação, a serem apresentados aos técnicos da DTDIE Poderá ser admitida a apresentação de procuração para a realização da vistoria, no entanto, além da procuração, deverão ser apresentados os seguintes documentos: identidade e CPF originais do procurador, original ou cópia autenticada do contrato social e cópia autenticada dos documentos de identificação citados no contrato social do procurado/ representante legal da empresa O representante legal da licitante, durante a VISTORIA TÉCNICA, deverá reconhecer, mediante assinatura do TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA- Anexo M, que fez visitas e teve ciência: Dos locais onde deverão ser realizados os serviços contratados; Da área destinada à CONTRATADA para execução dos serviços e quantidade de recursos materiais disponibilizados para sua equipe; Dos modelos de equipamentos servidores, armazenadores, integradores e de comunicação objeto dos serviços e utilizados pelo CONTRATANTE; Dos softwares, aplicativos e ferramentas auxiliares em utilização no momento da vistoria; Dos procedimentos adotados, documentação existente, modelos de acompanhamento, certificações existentes e recomendações legais da Organização; Ambiente de monitoramento e ferramentas utilizáveis para acompanhamento de disponibilidade e desempenho dos recursos de infraestrutura; Que recebeu da equipe técnica o detalhamento de hardwares, softwares e sistemas corporativos que deverão ser suportados tecnicamente pela empresa ganhadora do certame; O representante legal da licitante, para iniciar a vistoria, deverá assinar um TERMO DE CONFIDENCIALIDADE- Anexo K das informações técnicas repassadas pela equipe do 78

79 CONTRATANTE, por questões de segurança, procedimento adotado pelo Inep para repasse de informações que possam promover falhas de segurança O representante legal da licitante deverá entregar à equipe do CONTRATANTE, uma cópia da procuração ou autorização da empresa, em papel timbrado, em que constem informações identificadoras como nome e CPF do autorizado e CNPJ do autorizador e cópia da identidade do representante legal da licitante autenticada em cartório, para serem anexadas ao TERMO DE CONFIDENCIALIDADE- Anexo K Caso não seja apresentada a documentação acima exigida, será repassado para o representante legal da licitante, apenas os produtos e procedimentos que não promovam furos de segurança da informação. 11 VIGÊNCIA E GARANTIA CONTRATUAL 11.1 A vigência do contrato será de 12 (doze) meses, podendo ser prorrogado por iguais e sucessivos períodos, limitado a 60 (sessenta) meses, conforme previsto no inciso II do art. 57, da Lei nº 8.666/ Ocorrerá a repactuação visando a adequação aos novos preços de mercado, decorrido doze meses de vigência do Contrato, mediante negociação entre as partes e a demonstração analítica da variação dos componentes dos custos do contrato, devidamente justificada, mediante apresentação da planilha de custos A CONTRATADA, como garantia para o cumprimento das obrigações assumidas, fornecerá ao Inep, no ato da assinatura do contrato, a importância equivalente a 5% (cinco por cento) do valor contratual, em uma das modalidades previstas no art. 56, 1º, da Lei nº 8.666/ A CONTRATADA deverá prestar garantia contratual, no prazo máximo de 10 dias úteis contatos a partir da assinatura do contrato O valor da garantia permanecerá integral até o término da vigência do contrato. A reposição de seu valor, quando for o caso, será feita em até 72 (setenta e duas) horas, contadas da data de recebimento da notificação do Inep O valor da garantia reverterá, integralmente, em favor do Inep, ou pelo saldo que apresentar, no caso de rescisão contratual por culpa da CONTRATADA, sem prejuízo das perdas e danos porventura verificados O Inep poderá utilizar o valor da garantia prestada para descontar os valores referentes a eventuais multas aplicadas à CONTRATADA, bem como nos casos decorrentes de inadimplemento contratual, e de indenização por danos causados ao Patrimônio da União ou de terceiros, ocorridos nas suas dependências A garantia prestada pela CONTRATADA será liberada ou restituída após o término da vigência ou rescisão do contrato, desde que não haja pendências. Encaminha-se à Coordenação de Geral de Recursos Logísticos, Aquisições e Convênios da Diretoria de Gestão e Planejamento para abertura de processo administrativo objetivando iniciação de procedimento licitatório segundo art. 38 da Lei de 21 de junho de

80 EQUIPE DE PLANEJAMENTO DA CONTRATAÇÃO Integrante Técnico/Requisitante Integrante Administrativo Sérgio Soares da Silva Mat./SIAPE: Eduardo Almeida de Paula Ribeiro Mat./SIAPE: Brasília, de de AUTORIDADES COMPETENTES Coordenador Diretora da DTDIE. Diretor da DGP Cláudio Bernardes da Cunha Mat./SIAPE: Andrea de Miranda Ramos Kern Mat./SIAPE: Denio Menezes da Silva Mat./SIAPE: Brasília, de de

81 Anexos do Termo de Referência Anexo A- PORTFÓLIO DE ATIVIDADES E ARTEFATOS Anexo B- MODELO DE ORDEM DE SERVIÇO Anexo C- MODELO DE ORDEM DE SERVIÇO DE GARANTIA Anexo D- RELATÓRIO DE EXECUÇÃO DE SERVIÇO Anexo E- INDICADORES DE NÍVEIS DE SERVIÇOS Anexo F- RELATÓRIO PARA PAGAMENTO Anexo G- QUADRO DE RECURSOS DE TI Anexo H- RELAÇÃO DE SISTEMAS QUE COMPÕEM O LEGADO DO INEP Anexo I- TERMO DE CREDENCIAMENTO Anexo J- TERMO DE DESCREDENCIAMENTO Anexo K- TERMO DE CONFIDENCIALIDADE Anexo L - TERMO DE CIÊNCIA Anexo M- TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA Anexo N- TERMO DE COMPROMISSO Anexo O- PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS Anexo P- PERFIS PROFISSIONAIS E FORMAÇÃO EXIGIDA Anexo Q- QUADRO DE RECURSOS TÉCNICOS Anexo R- MGDS E GUIAS ADOTADOS PELO INEP 81

82 Anexo A- PORTFÓLIO DE ATIVIDADES E ARTEFATOS MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS Portfólio de Atividades e Artefatos Assessoria Tecnológica de Sistemas Referente ao Contrato /20 83

83 Sumário 1. PORTFÓLIO DE ATIVIDADES E ARTEFATOS FATOR DE PONDERAÇÃO NÍVEL DE COMPLEXIDADE NÍVEL DE IMPACTO NÍVEL DE CRITICIDADE TABELA PARA FATOR DE PONDERAÇÃO FATOR DE CONHECIMENTO INTERNO E MATURIDADE TABELA DE REFERÊNCIA PARA BALIZAR O FACIM: ATIVIDADES E ARTEFATOS PARA ANÁLISE DE ARQUITETURA DE SISTEMAS ATIVIDADES PARA ANÁLISE DE ARQUITETURA DE SISTEMAS ARTEFATOS PARA ANÁLISE DE ARQUITETURA DE SISTEMAS ATIVIDADES E ARTEFATOS PARA ANÁLISE DE NEGÓCIO PARA SISTEMAS ATIVIDADES PARA ANÁLISE DE NEGÓCIO PARA SISTEMAS ARTEFATOS PARA ANÁLISE DE NEGÓCIO PARA SISTEMAS TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS 97 ANEXO - MODELO DE REQUISIÇÃO DE NOVA ATIVIDADE OU ARTEFATO 99 84

84 1. PORTFÓLIO DE ATIVIDADES E ARTEFATOS Para a consecução dos serviços previstos no Objeto do Contrato /20 e no Termo de Referência, a CONTRATADA deverá elaborar os produtos e executar as atividades detalhadas neste Portfólio de Atividades e Artefatos. A elaboração desses produtos e/ou artefatos seguirá as metodologias e padrões utilizados pelo Inep. Essas metodologias e padrões poderão ser alteradas em virtude do processo natural de evoluções e melhorias implementadas pelo Inep e dos resultados dos serviços prestados pela CONTRATADA. 85

85 2. FATOR DE PONDERAÇÃO O Fator de Ponderação- FP- é a adoção de um valor de referência único buscando facilitar a contabilização dos serviços, exigindo do corpo técnico definição do fator de ponderação para a execução de cada atividade. Foram definidos três graus para o fator de ponderação: BAIXO, MÉDIO e ALTO. O grau do FP é indicado na OS para cada atividade, conforme aplicação, contexto e necessidades de execução, sendo definido a partir dos critérios: NÍVEL DE COMPLEXIDADE, NÍVEL DE IMPACTO, NÍVEL DE CRITICIDADE que cada atividade necessitar, conforme TABELA PARA FATOR DE PONDERAÇÃO. 2.1 Nível de Complexidade O Nível de Complexidade está relacionado diretamente com a natureza da atividade e o esforço necessário para a sua execução ou solução de incidente. BAIXO: Atividade que em sua natureza requer um baixo grau de esforço. MÉDIO: Atividade que requer razoável esforço, sendo necessário médio grau de análise para execução e/ou solução de incidentes. ALTO: Atividade que requer grande esforço, sendo necessário alto grau de análise para execução e/ou solução de incidentes. 2.2 Nível de Impacto O Nível de Impacto está relacionado ao efeito nos processos de negócio do Inep ou da DTDIE, o quanto os serviços serão afetados com falha, necessidade de evolução ou adaptação e qual será o transtorno, interno ou externo, pela não realização ou falha na execução da atividade. BAIXO: Contexto em que uma falha ou uma perda de performance não compromete os processos de negócio do Inep ou da DTDIE, com poucos usuários ou clientes e não afeta a imagem da organização ou diretoria. MÉDIO: Contexto em que uma falha ou uma perda de performance pode comprometer os processos de negócio do Inep ou da DTDIE, com poucos usuários ou clientes, podendo afetar a imagem da organização ou diretoria. ALTO: Contexto em que uma falha ou uma perda de performance compromete os processos de negócio do Inep ou da DTDIE, com muitos usuários ou clientes afetando a imagem da organização ou diretoria. 2.3 Nível de Criticidade O nível de criticidade está relacionado ao tempo de execução considerando que atrasos, na execução das atividades ou na entrega dos artefatos, podem afetar um processo de negócio do Inep ou da DTDIE. NORMAL: Contexto em que a atividade seguirá velocidade de trabalho normal devendo ser concluída em prazo normal, onde possíveis atrasos não afetarão os processos de negócios da organização ou diretoria. CRÍTICO: Contexto em que a atividade não pode ser adiada devendo ser executada rapidamente e com prazo reduzido para a execução, onde possíveis atrasos afetarão os processos de negócios da organização ou diretoria. 86

86 2.4 Tabela para Fator de Ponderação A Tabela para Fator de Ponderação é utilizada para definir do grau para o FP aplicado para as atividades a serem executadas. Complexidade Impacto Criticidade Fator de Ponderação B B N B B B C B B M N B B M C M B A N M B A C M M B N B M B C M M M N M M M C M M A N M M A C A A B N M A B C M A M N M A M C A A A N A A A C A LEGENDA B= BAIXO M= MÉDIO A= ALTO N=NORMAL C=CRÍTICO 87

87 3. FATOR DE CONHECIMENTO INTERNO E MATURIDADE O Fator de Conhecimento Interno e Maturidade- FACIM- é um indicador que baliza a perspectiva de definição do conhecimento interno e da maturidade para a execução das atividades. Este indicador tem o objetivo de criar um parâmetro que avalia o nível de maturidade e conhecimento do Inep que é transferido para o contexto da necessidade em que a atividade será inserida. Para apoiar na definição do FACIM segue como referência os seguintes critérios: DEFINIDO (D): As atividades são apoiadas por fortes subsídios de conhecimento e maturidade que serão temporariamente transferidos à contratada para auxiliar na execução das atividades. Considera-se como referência, entre outros: contexto em que as atividades têm necessidades, expectativas e restrições, tanto do serviço quanto de seus artefatos, identificadas; soluções são selecionadas para o serviço ou artefatos, com base em cenários definidos e em critérios identificados; apoiadas por guias estabelecidos e mantidos pelo Inep; alternativas de solução aceitáveis para o problema ou questão são identificadas; os riscos são identificados e documentados, incluindo seu contexto, condições de execução e possíveis consequências para as atividades e as partes interessadas. PARCIALMENTE DEFINIDO (PD): As atividades são apoiadas por relativo subsídio de conhecimento e maturidade que serão temporariamente transferidos à contratada para auxiliar na execução das atividades. Considera-se como referência, entre outros: contexto em que as atividades têm necessidades, expectativas e restrições, tanto do serviço quanto de seus artefatos, parcialmente identificadas; soluções são selecionadas para o serviço ou artefatos, com base em cenários parcialmente definidos e em critérios parcialmente identificados; não são apoiadas por guias estabelecidos e mantidos pelo Inep; alternativas de solução aceitáveis para o problema ou questão são parcialmente identificadas; os riscos são parcialmente identificados e parcialmente documentados, incluindo seu contexto, condições de execução e possíveis consequências para as atividades e as partes interessadas. INDEFINIDO (I): Não há subsídio de conhecimento e maturidade que possa ser temporariamente transferidos à contratada para auxiliar na execução das atividades. Considera-se como referência, entre outros: contexto em que as atividades têm necessidades, expectativas e restrições, tanto do serviço quanto de seus artefatos, não identificadas; soluções são selecionadas para o serviço ou artefatos, com base em cenários não definidos e em critérios não identificados; não é apoiado por guias estabelecidos e mantidos pelo Inep; alternativas de solução aceitáveis para o problema ou questão não são identificadas; os riscos não são identificados e documentados. 3.1 Tabela de referência para balizar o FACIM: FACIM ID FATOR Definido D 0,5 Parcialmente- Definido PD 1 Indefinido I 1,25 88

88 4. ATIVIDADES E ARTEFATOS PARA ANÁLISE DE ARQUITETURA DE SISTEMAS Prestação de serviços de suporte às atividades de arquitetura de sistemas. Tais atividades envolvem a formulação de proposta para ambiente de desenvolvimento, processos de configuração, mudança, elaboração de padrões tecnológicos a serem utilizados e arquitetura de referência; modelagem e implementação de soluções integradoras. 4.1 Atividades para Análise de Arquitetura de Sistemas Atividades GRAU/FP Desenvolvimento e manutenção de componentes. Suporte ao desenvolvimento de sistemas em componentes. Análise de documentação de arquitetura. Análise de melhor arquitetura de sistemas para solução de problemas. Prospecção de novas tecnologias para sistemas. Análise/investigação de código dos sistemas. FPQtd D FACIM= 0,5 QMA PD FACIM= 1 I FACIM= 1,25 BAIXO 16,00 8,00 16,00 20,00 MÉDIO 32,00 16,00 32,00 40,00 ALTO 53,28 26,64 53,28 66,60 BAIXO 4,00 2,00 4,00 5,00 MÉDIO 8,00 4,00 8,00 10,00 ALTO 13,32 6,66 13,32 16,65 BAIXO 16,00 8,00 16,00 20,00 MÉDIO 32,00 16,00 32,00 40,00 ALTO 53,28 26,64 53,28 66,60 BAIXO 16,00 8,00 16,00 20,00 MÉDIO 32,00 16,00 32,00 40,00 ALTO 53,28 26,64 53,28 66,60 BAIXO 40,00 20,00 40,00 50,00 MÉDIO 80,00 40,00 80,00 100,00 ALTO 133,20 66,60 133,20 166,50 BAIXO 32,00 16,00 32,00 40,00 MÉDIO 64,00 32,00 64,00 80,00 ALTO 106,56 53,28 106,56 133,20

89 Análise de desempenho. Suporte ao desenvolvimento para a qualidade do código. Análise de segurança. Configuração, otimização, melhorias e ajustes no servidor de desenvolvimento. Deploys e configuração de datasources para servidor de desenvolvimento. Manutenção da ferramenta de configuração e mudança no servidor de desenvolvimento. Análise de logs, problemas e conflitos nas aplicações. Manutenção do repositório de bibliotecas de componentes. Configuração e otimização nas aplicações em produção. BAIXO 32,00 16,00 32,00 40,00 MÉDIO 64,00 32,00 64,00 80,00 ALTO 106,56 53,28 106,56 133,20 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 40,00 20,00 40,00 50,00 MÉDIO 80,00 40,00 80,00 100,00 ALTO 133,20 66,60 133,20 166,50 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 4,00 2,00 4,00 5,00 MÉDIO 8,00 4,00 8,00 10,00 ALTO 13,32 6,66 13,32 16,65 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 16,00 8,00 16,00 20,00 MÉDIO 32,00 16,00 32,00 40,00 ALTO 53,28 26,64 53,28 66,60

90 Análise de problemas e conflitos em aplicações. Desenvolvimento de features (rotinas) de monitoração. Gerenciamento de bibliotecas de componentes de sistemas. Auditoria de log de erros dos sistemas em produção. BAIXO 16,00 8,00 16,00 20,00 MÉDIO 32,00 16,00 32,00 40,00 ALTO 53,28 26,64 53,28 66,60 BAIXO 16,00 8,00 16,00 20,00 MÉDIO 32,00 16,00 32,00 40,00 ALTO 53,28 26,64 53,28 66,60 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33, Artefatos para Análise de Arquitetura de Sistemas ID AA1 AA2 AA3 Artefatos Relatório de Atividades Documento de Arquitetura

91 5. ATIVIDADES E ARTEFATOS PARA ANÁLISE DE NEGÓCIO PARA SISTEMAS Prestação de serviços de suporte às atividades de análise de negócio, envolvendo o domínio e a aplicação de técnicas utilizadas para identificar e relacionar partes interessadas e documentar suas necessidades, requisitos e regras, no intuito de compreender a estrutura, as políticas e operações das diversas áreas de negócio do Inep, viabilizando o alcance das metas organizacionais a partir da adoção de soluções de TI. 5.1 Atividades para Análise de Negócio para Sistemas Atividades Aplicar técnicas de elicitação no intuito de compreender as necessidades e preocupações das partes interessadas e os ambientes no qual elas trabalham ou operam. Participar de reuniões com clientes e gestores de negócio, identificando suas necessidades e oportunidades no âmbito de seu ambiente de negócios. Identificar e documentar os princípios e práticas de negócio. Registrar o conhecimento da organização que se encontra centrado em alguns gestores da organização. Registrar as soluções existentes e aplicadas a determinadas áreas de negócio. Identificar os problemas e oportunidades do negócio através da análise da situação do negócio. GRAU/FP FPQtd D FACIM= 0,5 QMA PD FACIM= 1 I FACIM= 1,25 BAIXO 40,00 20,00 40,00 50,00 MÉDIO 80,00 40,00 80,00 100,00 ALTO 133,20 66,60 133,20 166,50 BAIXO 1,00 0,50 1,00 1,25 MÉDIO 2,00 1,00 2,00 2,50 ALTO 3,33 1,67 3,33 4,16 BAIXO 40,00 20,00 40,00 50,00 MÉDIO 80,00 40,00 80,00 100,00 ALTO 133,20 66,60 133,20 166,50 BAIXO 4,00 2,00 4,00 5,00 MÉDIO 8,00 4,00 8,00 10,00 ALTO 13,32 6,66 13,32 16,65 BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 16,00 8,00 16,00 20,00 MÉDIO 32,00 16,00 32,00 40,00 ALTO 53,28 26,64 53,28 66,60

92 Elucidar a mudança necessária para atender às necessidades do negócio e atingir as metas estratégias através da avaliação das capacidades da organização. BAIXO 40,00 20,00 40,00 50,00 MÉDIO 80,00 40,00 80,00 100,00 ALTO 133,20 66,60 133,20 166,50 Desenvolver artefato que apresente a solução proposta a partir da definição do escopo da solução. Definir e documentar os requisitos do negócio (incluindo a necessidade do negócio, capacidades requeridas, escopo da solução e plano de negócios). BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 BAIXO 24,00 12,00 24,00 30,00 MÉDIO 48,00 24,00 48,00 60,00 ALTO 79,92 39,96 79,92 99,90 Definir a necessidade do negócio: Identificar porque uma mudança nas capacidades ou sistemas organizacionais é necessária (a razão de ser da iniciativa). Trata-se da definição do problema para o qual o analista está tentando encontrar a solução. A definição da necessidade do negócio orienta quais soluções serão consideradas, quais partes interessadas serão consultadas e quais abordagens de solução serão aceitas. BAIXO 40,00 20,00 40,00 50,00 MÉDIO 80,00 40,00 80,00 100,00 ALTO 133,20 66,60 133,20 166,50 Avaliar lapsos de capacidade: Identificação de quais são as capacidades necessárias para a organização atender à necessidade do negócio. Essas capacidades (estrutura, pessoas, processos e tecnologia) podem já ser possuídas pela organização, o que faz a mudança tender a ser pequenas, ou não, o que tende a envolver iniciativas mais complexas. BAIXO 24,00 12,00 24,00 30,00 MÉDIO 48,00 24,00 48,00 60,00 ALTO 79,92 39,96 79,92 99,90 Definir o escopo da solução: Definição de quais são as novas capacidades que a iniciativa (ou parte de uma iniciativa) deverá entregar. BAIXO 8,00 4,00 8,00 10,00 MÉDIO 16,00 8,00 16,00 20,00 ALTO 26,64 13,32 26,64 33,30 Participar de reuniões com gestores da área de TI para avaliar os recursos disponíveis e a necessidade de novas aquisições. BAIXO 1,00 0,50 1,00 1,25 MÉDIO 2,00 1,00 2,00 2,50 ALTO 3,33 1,67 3,33 4,16

93 5.2 Artefatos para Análise de Negócio para Sistemas ID AN1 AN2 AN3 AN4 AN5 AN6 AN7 AN8 AN9 AN10 Artefatos Ata de Reunião. Visão de Negócio. Documento de Arquitetura. Documento de Requisitos do Negócio. Business Case. Relatório de Soluções de Negócio. Visão de Processos de Negócio. Relatório de Oportunidades de Negócio. Plano de Mudança no Negócio. Relatório de Impacto no Negócio.

94 6. TABELA DE REFERÊNCIA PARA AVALIAÇÃO DOS ARTEFATOS Todos os artefatos entregues ao Inep deverão ter registro da VERIFICAÇÃO DA QUALIDADE, assegurando a conformidade dos padrões e requisitos exigidos pelo Inep, apoiados pela Tabela de Referência para Avaliação dos Artefatos. A tabela possui três indicações que serão informadas pelo REQUISITANTE e FISCAL TÉCNICO do Inep conforme execução das atividades solicitadas na OS. SIM: Significa que os artefatos estão de acordo com a descrição do item avaliado. NÃO: Significa que os artefatos não estão de acordo com a descrição do item avaliado. NÃO SE APLICA: Significa que o item avaliado não será considerado para a avaliação por motivos específicos da necessidade ou do artefato. A indicação NÃO em qualquer dos itens da Tabela de Referência para Avaliação dos Artefatos implicará a indicação de NÃO ACEITO na OS. Os itens da Tabela de Referência para Avaliação dos Artefatos poderão sofrer alterações durante a execução do contrato, podendo ser excluídos os critérios vigentes ou incluídos novos critérios conforme as necessidades de negócio do Inep. 6.1 Tabela de Referência para Avaliação dos Artefatos Tabela de Referência para Avaliação dos Artefatos ITEM DESCRIÇÃO S N NA 1 O conteúdo do artefato está em conformidade com os guias, metodologias e padrões estabelecidos pelo Inep. 2 A escrita no artefato está correta, redigido de forma clara, garantindo bom entendimento e evitando mais de uma interpretação em relação ao objetivo para o qual foi escrito. 3 O artefato produzido está adequadamente armazenado nas ferramentas de suporte à Engenharia de Software sem duplicidade de artefato ou informação, sem conflito entre artefatos ou informações, sem repetição desnecessária de artefatos ou informações, no mesmo artefato ou entre outros artefatos. 4 O artefato segue estritamente a formatação definida com os principais responsáveis pelo artefato ou serviço precisamente identificados. 5 O artefato está relacionado ao serviço e atendem ao solicitado na OS.

95 Anexo - MODELO DE REQUISIÇÃO DE NOVA ATIVIDADE OU ARTEFATO MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS REQUISIÇÃO DE NOVA ATIVIDADE OU ARTEFATO ÁREA DE APLICAÇÃO DA ATIVIDADE OU ARTEFATO: ANÁLISE DE ARQUITETURA DE SISTEMAS ANÁLISE DE NEGÓCIO PARA SISTEMAS IDENTIFICAÇÃO DA ATIVIDADE OU ARTEFATO: ID: NOME: OBJETIVO E DESCRIÇÃO DA NECESSIDADE: INDICAÇÃO DE MAT PARA FATOR DE PONDERAÇÃO: Fator de Ponderação BAIXO MÉDIO ALTO Quantidade de MAT Definido pelo Corpo Técnico da DTDIE 2 X ( a quantidade do BAIXO) 3,33 X (a quantidade do BAIXO) Ciente e Autorizada Inclusão Assinatura Fiscal Requisitante: Assinatura Fiscal Técnico: Assinatura Gestor do Contrato:

96 Anexo B- MODELO DE ORDEM DE SERVIÇO MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS ORDEM DE SERVIÇO Contrato: /20 OS Nº Data: / / Hora : Descrição da necessidade: ÁREA DE ASSESSORIA: ANÁLISE DE ARQUITETURA DE SISTEMAS ANÁLISE DE NEGÓCIO PARA SISTEMAS Atividades Requeridas ID ATIVIDADE FP FACIM QMA Artefatos Requeridos ID ARTEFATOS PRAZO: Data: / / Hora : Fiscal Requisitante: Fiscal Técnico:

97 Emitido em: Data: / / Hora : Gestor do Contrato: Observações: Recepcionada em: Data: / / Preposto: Hora : Observações: Execução Finalizada: Data: / / Hora : Avaliação da Ordem de Serviço Fiscal Técnico: ACEITO NÃO ACEITO Justificativa: Fiscal Requisitante: ACEITO NÃO ACEITO Justificativa: Prazo para Correção(em avaliação Não Aceito ): Data: / / Hora : Conclusão OS(em avaliação Aceito ): Data: / / Hora : Observações: TOTAL DE MAT: TOTAL DE AVALIAÇÕES NÃO ACEITO : Gestor do Contrato:

98 Anexo C- MODELO DE ORDEM DE SERVIÇO DE GARANTIA MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS ORDEM DE SERVIÇO DE GARANTIA Contrato: /20 OSG Nº Data: / / Hora : Referente à Ordem de Serviço: Descrição da necessidade ou Problema: Atividades Requeridas ID ATIVIDADE Artefatos Requeridos ID ARTEFATOS PRAZO: Data: / / Hora : Fiscal Requisitante: Fiscal Técnico: Emitido em: Data: / / Hora : Gestor do Contrato:

99 Observações: Recepcionada em: Data: / / Preposto: Hora : Observações: Execução Finalizada: Data: / / Hora : Avaliação da Ordem de Serviço de Garantia Fiscal Técnico: ACEITO NÃO ACEITO Justificativa: Fiscal Requisitante: ACEITO NÃO ACEITO Justificativa: Prazo para Correção(em avaliação Não Aceito ): Data: / / Hora : Conclusão OS(em avaliação Aceito ): Data: / / TOTAL DE AVALIAÇÕES NÃO ACEITO : Hora : Observações: Gestor do Contrato:

100 Anexo D- MODELO DE RELATÓRIO DE EXECUÇÃO DE SERVIÇO MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS RELATÓRIO DE EXECUÇÃO DE SERVIÇO Contrato: /20 Referente à Ordem de Serviço Nº Data: / / Hora : Descrição da necessidade: ÁREA DE ASSESSORIA: ANÁLISE DE ARQUITETURA DE SISTEMAS ANÁLISE DE NEGÓCIO PARA SISTEMAS Atividades Requeridas ID ATIVIDADE Artefatos Requeridos ID ARTEFATOS

101 Detalhamento da Execução das Atividades Nº DESCRIÇÃO Tempo Impedimentos de Execução Sugestão de Melhorias para as Atividades ou Processos

102 Anexo E- INDICADORES DE NÍVEIS DE SERVIÇOS MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS INDICADORES DE NÍVEIS DE SERVIÇOS Os INDICADORES DE NÍVEIS DE SERVIÇOS (INS) são um conjunto de critérios objetivos e mensuráveis estabelecidos entre a CONTRATANTE e a CONTRATADA com a finalidade de aferir e avaliar diversos indicadores relacionados com os serviços contratados, conforme tabelas apresentadas. Nos INS estão definidos: a maneira pela qual estes fatores serão avaliados; o nível mínimo aceitável; e as glosas a serem aplicadas na quantidade de MAT faturadas MENSALMENTE, quando o serviço prestado não alcançar o nível máximo esperado. A frequência de aferição e avaliação dos níveis de serviço será mensal. Ficam estabelecidos os seguintes Indicadores de Níveis de Serviço- INS: INS1- Indicador de Nível de Serviço N 1 Definição: Execução das OS, OSG e entrega dos artefatos no prazo solicitado. Fórmula: Para a aferição do indicador será utilizada a seguinte fórmula: INS1 = Indicador de Nível de Serviço 1 OSFP = Total de OS e OSG entregues fora do prazo no mês OS = Total de OS e OSG no mês Tabela de verificação INS1: INS1 Glosas na Fatura Igual ou superior a 26% Multa+GLOSA de 5% De 21% a 25,99% 5% De 16% a 20,99% 4% De 11% a 15,99% 3%

103 De 6% a 10,99% 2% De 1% a 5,99% 1% De 0% a 0,99% 0% INS2-Indicador de Nível de Serviço N 2. Definição: Quantidade de avaliações que obtiveram indicação de NÃO ACEITO na VERIFICAÇÃO DA QUALIDADE. Fórmula: Para a aferição do indicador será utilizada a seguinte fórmula: INS2= Indicador de Nível de Serviço 2 AVNA= Total de Avaliações com indicação NÃO ACEITO no mês AVM=Total de avaliações do mês Tabela de verificação INS2: INS2 Glosas na Fatura Igual ou superior a 26% Multa+GLOSA de 5% De 21% a 25,99% 5% De 16% a 20,99% 4% De 11% a 15,99% 3% De 6% a 10,99% 2% De 1% a 5,99% 1% De 0% a 0,99% 0% INS3- Indicador de Nível de Serviço Nº3 Definição: Quantidade de ORDENS DE SERVIÇO DE GARANTIA- OSG geradas no mês. Fórmula: Para a aferição do indicador será utilizada a seguinte fórmula: INS3= Indicador de Nível de Serviço 3 TOSG= Total de OSG geradas no mês TOS= Total de OS geradas no mês Tabela de verificação INS3:

104 INS3 Glosas na Fatura Igual ou superior a 16% Multa+GLOSA de 5% De 11% a 15,99% 5% De 6% a 10,99% 3% De 1% a 5,99% 1% De 0% a 0,99% 0% O melhor desempenho para todos os INS é 0%(zero por cento), garantindo os critérios de qualidade esperados e não incidindo glosas sobre a fatura mensal. Os Indicadores de Níveis de Serviços estão agrupados em faixas de valores percentuais. Para cada uma dessas faixas há a previsão de um percentual de glosa sobre a fatura mensal. Na FAIXA MÁXIMA TOLERÁVEL para os valores dos INS o valor percentual da glosa que incidirá sobre a fatura mensal será de 5%. No caso do INS1 e INS2, a FAIXA MÁXIMA TOLERÁVEL (onde a glosa é de 5%) é delimitada pelos valores percentuais compreendidos no intervalo de 21% a 25,99%. Para o INS3 a FAIXA MÁXIMA TOLERÁVEL (onde a glosa é de 5%) é delimitada pelos valores compreendidos no intervalo de 11% a 15,99%. As glosas por INS são cumulativas até o limite de 15% (quinze por cento) do total de MAT faturado no mês. O valor máximo tolerável é de 25,99% (vinte e cinco vírgula noventa e nove por cento) para os INS1 e INS2, para o INS3 é de 15,99% (quinze vírgula noventa e nove por cento). Ultrapassando esses limites, além da glosa prevista, será aplicada uma MULTA por DESCUMPRIMENTO DE ACORDO DE NÍVEIS DE SERVIÇO. É limitado à CONTRATADA atingir a FAIXA MÁXIMA TOLERÁVEL para até 1 (um) INS, superando-se este limite será aplicado, além das glosas previstas, uma MULTA por DESCUMPRIMENTO DE ACORDO DE NÍVEIS DE SERVIÇO. As glosas não são consideradas como SANÇÃO/PENALIDADE para a execução contratual, são mecanismos contratuais que buscam o equilíbrio entre o que se espera de qualidade nos serviços e o que é entregue pela CONTRATADA.

105 Anexo F- MODELO DO RELATÓRIO PARA PAGAMENTO MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS RELATÓRIO PARA PAGAMENTO N : Referente ao Mês: Data: / / Relatório de Ordens de Serviço e Ordens de Serviço de Garantia Total de OS: Total de OS Fora do Prazo: Total de OSG: Total de OSG Fora do Prazo: Total: Total Fora do Prazo: Detalhamento das Ordens de Serviço Concluídas N Área de Atividade Prazo Requerido Prazo Executado Qtd. MAT Observações: Relatório de Avaliação da Qualidade Total de indicação com ACEITO : Total de indicação com NÃO ACEITO : Total de Avaliações: Observações:

106 Relatório de Indicadores de Nível de Serviço INS1: % Glosa Prevista: % INS2: % Glosa Prevista: % INS3: % Glosa Prevista: % Total de Glosa: % Observações: Relatório de Faturamento Volume Mensal de MAT: Volume Mensal de Glosas: Volume Mensal de Pagamento: Valor de Pagamento: % R$ MAT de Glosa: Em cumprimento ao contrato nº /20, informamos que o Relatório para Pagamento, enviado pela empresa, foi devidamente analisado. Deste modo, autorizamos o faturamento referente às Ordens de Serviços constantes neste relatório, totalizando MAT, considerando as glosas previstas, com VALOR DE PAGAMENTO R$. Brasília-DF de de 20. Gestor do Contrato

107 Anexo G- QUADRO DE RECURSOS DE TI MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS 1. Princípios QUADRO DE RECURSOS DE TI A plataforma de hardware e software do ambiente computacional implantado e a metodologia para administração adotada visam atender, prioritariamente, os seguintes princípios: Escalabilidade, possibilitando o crescimento modular; Capacidade, viabilizando o gerenciamento de grandes volumes de dados e tabelas; Conectividade, permitindo o acesso aos dados por usuários internos e externos ao Tribunal, a partir de protocolos de rede múltiplos; Desempenho, garantindo o acesso simultâneo de número expressivo de usuários do Tribunal e de instalações externas, governamentais ou não; Disponibilidade, dotando o ambiente corporativo de um nível aceitável de tolerância a falhas; Continuidade, normatizando e divulgando as áreas responsáveis os procedimentos e processos de execução dos serviços, mediante documentação organizada e padronizada dos processos de execução dos serviços; Controle, efetuando registros de todos os problemas, alterações, implementações realizadas no ambiente computacional; Segurança, prevendo mecanismos de controle de acesso às informações e ferramentas que garantam a integridade, confidencialidade e confiabilidade dos dados; Governança, adequando todos os procedimentos, processos, documentações e execução de serviços em plena compatibilidade com as melhores práticas utilizadas pelo mercado ou com os modelos adotados pelo Tribunal. Proatividade, executando os procedimentos e manutenções proativas de forma a proporcionar mais estabilidade dos recursos disponibilizados. Eficiência, apresentando e aplicando a solução necessária para o problema detectado no menor prazo possível. Eficácia, aplicando e implementando recursos que promovam a estabilização dos serviços e de acordo com os processos e procedimentos adotados pelo Tribunal. Padronização, efetuando as atividades mediante documentação técnica detalhada quanto aos procedimentos de realização, modeladas conforme conhecimento técnico da equipe e fundamentada nas melhores práticas de mercado.

108 2. Infraestrutura de Rede 2.1 Resumido Servidores de Rede: 117; Sistema Operacional: Linux, Windows, Virtualização; Serviços de Rede: Internet, , Ftp Voip, Wireless, Storage, Antivírus, Firewall, filtro de conteúdo web (Ironport e Squid), Antispam, Servidor de Arquivos, Active Directory; 2.2 Detalhado Servidores de Rede: 33 - Servidores Dell modelo power edge Servidores Dell modelo power edge R Servidores Dell modelo power edge R Servidores IBM system x Servidores Sun fire Servidores HP. 3. Sistema Operacional: Redhat versões 4 e 5 CentOS Debian Oracle Linux Windows NT Enterprise 2008 Standard/Enterprise 2008 R2 Standard/Enterprise 4. Para Virtualização: Vmware Esx Rhev 5. Serviços de Rede: Internet (apache e jboss), , Ftp Voip, Wireless, Storage, Antivírus, Firewall, filtro de conteúdo, Antispam, Servidor de Arquivos, Active Directory, Roteadores Cisco 2cores nortel Passport, 10 Switch Cisco, 25 Switch 3Com Banco de Dados: Banco de Dados Oracle 10g/11g: 6 BD produção, 6 BD homologação e 2 BD desenvolvimento. Postgres: 1 BD produção, 1 desenvolvimento. MySQL: 1 BD produção, 1 desenvolvimento. 7. Linguagens de Desenvolvimento Plataformas Web: Servidor: Java, PHP e ASP; Cliente: JavaScript, VBScript, HTML, XHTML e CSS. Desktop: Java, Delphi e VB. 8. Servidor de Aplicação JBoss 4x ou superior. Joomla! 9. Servidor de Portal

109 10. Servidor Web Apache; IIS. 11. Servidor de Correio Eletrônico Microsoft Exchange Server Sistema de Diretório Microsoft Active Directory. 13. Sistema de Armazenamento Storage Netapp. 14. Ferramentas de Apoio ao Desenvolvimento Subversion; Continuum; Apache Maven; JMeter; Mantis; Eclipse; NetBeans; MS Office; BR Office; JDeveloper. 15. Ferramentas de Apoio a Análise BizAgi Process Modeler; FreeMind; Jude; Power Architect; JDeveloper; Eclipse. 16.Ferramentas de Apoio a Modelagem de Banco de Dados Power Architect; Data Modeler; JDeveloper. CCP. 17. Ferramenta de Gerenciamento de Projetos e Contratos 18. Ferramenta de Controle de Demandas Simec Demandas; Inep Demandas. 19. Ferramentas de Monitoramento / Gestão de Lan e/ou Wan Zabbix 1.8; Cacti ; Jboss Operation Network. 20. Antivírus McAfee versão 8.7 i. 21. Backup BrightStor ARCserver Backup.

110 22. Pontos de rede: 650 Computadores 110 Notebooks 50 impressoras 8 projetores 23.Outros dados de resposta da área de Segurança de TI Seguem os dados aproximados: s: entradas incluindo spam por dia saídas por dia Visitas ao site: visitas por mês com picos de em alguns meses e picos de em um dia.

111 Anexo H- RELAÇÃO DE SISTEMAS QUE COMPÕEM O LEGADO DO INEP MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS RELAÇÃO DE SISTEMAS QUE COMPÕEM O LEGADO DO INEP Nome do Sistema Descrição Tecnologia Automação AAE - Pagamento de Avaliadores Enem ENCCEJA Celpe-Bras Prova Brasil O sistema Auxílio de Avaliação Educacional é responsável pelo controle do pagamento de avaliadores institucionais. O Enem é o Exame Nacional do Ensino Médio. O sistema é responsável pela coleta de inscrições dos participantes, pela divulgação dos locais de prova e pela divulgação dos resultados. O Exame Nacional para Certificação de Competências de Jovens e Adultos (Encceja) é um instrumento de avaliação que mede as competências e habilidades de jovens e adultos, residentes no Brasil e no exterior, em nível de conclusão do Ensino Fundamental. O sistema é responsável pela coleta de inscrições dos participantes, pela divulgação dos locais de prova e pela divulgação dos resultados. O Celpe-Bras é o Certificado de Proficiência em Língua Portuguesa para Estrangeiros. No País, o exame é exigido pelas universidades, para ingresso em cursos de graduação e pós-graduação, além de servir para legitimar os diplomas de profissionais estrangeiros que pretendem trabalhar no país. O sistema é responsável pela coleta de inscrições dos interessados em realizar o exame. Em breve, os participantes poderão acessar seus boletins de desempenho individual também pelo sistema. O Prova Brasil é um exame que avalia o rendimento escolar de estudantes de 4ª e 8ª séries do ensino fundamental. O sistema é responsável pela divulgação dos resultados do Prova Java com PostGreSQL Java com Oracle Java com Oracle Java com Oracle Java com Oracle

112 Banco de Itens do ENCCEJA SAEB IDEB BNI Provinha Brasil Enade E-Mec Siedsup Brasil. O sistema é responsável por armazenar as questões utilizadas na elaboração das provas do ENCCEJA. O SAEB é um exame que avalia o rendimento escolar de estudantes de 4ª e 8ª séries do ensino fundamental e também estudantes do 3º ano do ensino médio. O sistema é responsável pela divulgação dos resultados do SAEB. O sistema é responsável por divulgar o Índice de Desenvolvimento da Educação Básica (IDEB). O sistema é responsável por armazenar as questões utilizadas na elaboração das provas do SAEB, do Prova Brasil e do Enem. A Provinha Brasil é uma avaliação diagnóstica do nível de alfabetização das crianças matriculadas no segundo ano de escolarização das escolas públicas brasileiras. O sistema é responsável por disponibilizar o material didático para aplicação do exame pelas escolas participantes. O Exame Nacional de Desempenho de Estudantes tem o objetivo de aferir o rendimento dos alunos dos cursos de graduação em relação aos conteúdos programáticos, suas habilidades e competências. O sistema é responsável pela coleta de inscrições dos participantes, pela divulgação dos locais de prova e pela divulgação dos resultados. Sistema responsável pela tramitação eletrônica dos processos (credenciamento e recredenciamento de Instituições Superiores de Ensino IES, autorização, reconhecimento e renovação de reconhecimento de cursos), armazenamento de currículos dos docentes das IES, dados dos avaliadores e designação de comissão de avaliadores institucionais. Sistema responsável pelo cadastramento de instituições e de cursos do ensino superior. Java com Oracle Delphi com Oracle PHP com Oracle Delphi com Oracle Java com Oracle Java com Oracle PHP com PostGreSQL ASP(Componentes em Visual Basic) com Oracle

113 Anexo I- MODELO DO TERMO DE CREDENCIAMENTO TERMO DE CREDENCIAMENTO A empresa <nome da empresa> CNPJ <nº CNPJ>, Contrato <nº do contrato>, Endereço: <endereço>, vem por meio deste Termo solicitar o credenciamento e liberação de acesso às dependências do Inep dos seguintes funcionários abaixo identificados: Nome do funcionário Documentos RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: RG: CPF: Matrícula na empresa: Brasília-DF,, de de 20. <Nome da empresa> <Assinatura do Representante legal>

114 Anexo J- MODELO DO TERMO DE DESCREDENCIAMENTO TERMO DE DESCREDENCIAMENTO A empresa <nome da empresa> CNPJ <nº CNPJ>, Contrato <nº do contrato>, Endereço: <endereço>, vem por meio deste Termo solicitar o descredenciamento e o cancelamento da liberação de acesso às dependências do Inep do Funcionário <nome>, RG <nº RG>, CPF <nº CPF>. Informamos ainda que estamos devolvendo os seguintes materiais que estavam de posse do funcionário acima relacionado: ões certificadores Pen drive <especificar> Brasília-DF,, de de 20. <Nome da empresa> <Assinatura do Representante legal>

115 Anexo K- MODELO DO TERMO DE CONFIDENCIALIDADE MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS TERMO DE CONFIDENCIALIDADE Pelo presente Termo de Responsabilidade, eu, (dados civis), CPF nº, RG nº, (órgão emissor), representante da empresa, CNPJ nº, declaro ter recebido do Inep as informações complementares sobre os recursos de TI que embasarão nossa proposta orçamentária no respectivo certame. Por meio do presente termo de responsabilidade a empresa signatária, participante da licitação em epígrafe, compromete-se a manter sob sigilo as informações e dados obtidos, comprometendo-se a destruir todas as informações obtidas caso não seja sagrada vencedora do certame. Sob as penas da Lei, comprometo-me a não divulgar as informações a que tive acesso. Brasília, / /2012 Carimbo e assinatura do Responsável pela Vistoria Técnica Nome da Empresa: CNPJ da Empresa: Nome do representante do INEP Matrícula:

116 Anexo L- MODELO DO TERMO DE CIÊNCIA MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS Contrato N : Objeto: TERMO DE CIÊNCIA Gestor: SIAPE: Contratante: Contratada: Preposto: CNPJ: CPF: Por este instrumento, os funcionários abaixo-assinados declaram ter ciência e conhecer a declaração de manutenção de sigilo e das normas de segurança vigentes na Contratante. Brasília- DF, de de 20. CIÊNCIA Funcionários da Contratada <Nome> Matricula: CPF: <Nome> Matricula: CPF: <Nome> Matricula: CPF: <Nome> Matricula: CPF: <Nome> Matricula: CPF: <Nome> Matricula: CPF: <Nome> Matricula: CPF: <Nome> Matricula: CPF:

117 Anexo M- TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS TERMO DE REALIZAÇÃO DE VISTORIA TÉCNICA Declaro, para fins de participação no Pregão Eletrônico nº, que tomei conhecimento de todas as informações necessárias para a identificação dos serviços licitados, bem como vistoriei os equipamentos e ambientes em que serão prestados os serviços, tomei conhecimento e cumpri as exigências expressas no Edital, tendo sido sanada pela equipe técnica do Inep todas as dúvidas que porventura foram por mim questionadas e que marquei de próprio punho os itens abaixo. Entreguei o termo de confidencialidade. ficação e dados do termo de confidencialidade foram conferidos pela equipe técnica. Resumo descritivo da Vistoria. ão dos serviços. ão dos serviços, e os recursos materiais disponibilizados para a equipe contratada. hardwares e periféricos objeto dos serviços. softwares, aplicativos e ferramentas auxiliares em utilização nos computadores servidores e estações de trabalho. ão existente, modelos de acompanhamento, certificações existentes, recomendações e normatizações da organização. evida especialização necessária para a execução dos serviços a serem contratados. ão e características técnicas adotadas pelo CONTRATANTE. Brasília-DF, de de 20. Carimbo e assinatura do Responsável pela Vistoria Técnica Nome da Empresa: CNPJ da Empresa: Representante do Inep Matrícula:

118 Anexo N- TERMO DE COMPROMISSO MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS TERMO DE COMPROMISSO Este Termo de Compromisso ( Termo ) é celebrado entre: CONTRATANTE Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira -Inep, Endereço Setor de Rádio e TV Sul SRTVS Quadra 701, Bloco M Brasília/DF, inscrita no CNPJ/MF / , neste ato representada pelo Gestor do Contrato xx/xxxx, e CONTRATADA xxxxxxxx, Endereço xxxxxxxx, inscrita no CNPJ/MF xxxxxx, personificação xxxxxx, neste ato representada por seus respectivos procuradores abaixo assinados, na forma de seus respectivos Contratos Sociais. O Inep e a CONTRATADA podem ser referidas individualmente como Parte e coletivamente como Partes, onde o contexto assim o exigir. CONSIDERANDO que as Partes estabeleceram ou estão considerando estabelecer uma relação de negócio que inclui a prestação de serviços na área de Tecnologia da Informação para ASSESSORIA TECNOLÓGICA EM SISTEMAS DE INFORMAÇÃO E PROCESSOS; CONSIDERANDO QUE as Partes podem divulgar entre si Informações Confidenciais, conforme definido abaixo neste instrumento, sobre aspectos de seus respectivos negócios, e em consideração da divulgação destas Informações Confidenciais; CONSIDERANDO QUE as Partes desejam ajustar as condições de revelação das Informações Confidenciais, bem como definir as regras relativas ao seu uso e proteção; RESOLVEM as Partes celebrar o presente Termo de Compromisso de Manutenção de Sigilo, o qual se regerá pelas considerações acima, bem como pelas cláusulas e condições a seguir: 1. Para a finalidade deste Termo, Informações Confidenciais significarão todas e quaisquer informações divulgadas por uma Parte (de acordo com este instrumento, a Parte Divulgadora ) à outra Parte (de acordo com este instrumento, a Parte Recebedora ), em forma escrita ou verbal, tangível ou intangível, patenteada ou não, de natureza técnica, operacional, comercial, jurídica, a qual esteja claramente marcada como CONFIDENCIAL, incluindo, entre outras, mas não se limitando a, segredos comerciais, know-how, patentes, pesquisas, planos de negócio, informações de marketing, informações de usuários, situação financeira, métodos de contabilidade, técnicas e experiências acumuladas, e qualquer outra informação técnica, comercial e/ou financeira, seja expressa em notas, cartas, fax, memorandos, acordos, termos, análises, relatórios, atas, documentos, manuais, compilações, código de software, , estudos, especificações, desenhos, cópias, diagramas, modelos, amostras, fluxogramas, programas de computador, discos, disquetes, fitas, pareceres e pesquisas, ou divulgadas verbalmente e identificadas como confidenciais por ocasião da divulgação.

119 2. Não serão incluídas nas Informações Confidenciais quaisquer informações que: (i) sejam geralmente conhecidas, ou subsequentemente se tornem disponíveis ao comércio ou ao público; (ii) estejam na posse legal da Parte Recebedora antes da di vulgação pela Parte Divulgadora; ou (iii) sejam legalmente recebidas pela Parte Recebedora de um terceiro, desde que essas informações não tenham chegado ao conhecimento da Parte Recebedora através do referido terceiro, direta ou indiretamente, a partir da Parte Divulgadora numa base confidencial. 3. Quando a divulgação de Informações Confidenciais for necessária para estrito atendimento de ordem judicial ou agência governamental, o mesmo se procederá da seguinte maneira: (i) a Parte Recebedora fica obrigada a comunicar o teor da determinação judicial à Parte Divulgadora no prazo de 2 (dois) dias úteis a contar do recebimento da ordem, no caso de se tratar de determinação para cumprimento em prazo máximo de 5 (cinco) dias; ou no prazo de uma hora a contar do recebimento, no caso de se tratar de ordem judicial para cumprimento no prazo máxima de até 48 (quarenta e oito) horas; e (ii) fica a Parte Recebedora obrigada também a enviar à Parte Divulgadora cópia da resposta dada à determinação judicial ou administrativa concomitantemente ao atendimento da mesma. A Parte Recebedora cooperará com a Parte Divulgadora para possibilitar que a Parte Divulgadora procure uma liminar ou outra medida de proteção para impedir ou limitar a divulgação dessas Informações Confidenciais. 4. A Parte Recebedora não divulgará nenhuma Informação Confidencial da Parte Divulgadora a nenhum terceiro, exceto para a finalidade do cumprimento deste Termo e com o consentimento prévio por escrito da Parte Divulgadora. Além disso: I. A Parte Recebedora, (i) não usará as Informações Confidenciais para interferir, direta ou indiretamente, com nenhum negócio real ou potencial da Parte Divulgadora, e (ii) não usará as Informações Confidenciais para nenhuma finalidade, exceto avaliar uma possível relação estratégica entre as Partes. II. As Partes deverão proteger as Informações Confidenciais que lhe forem divulgadas, usando o mesmo grau de cuidado utilizado para proteger suas próprias Informações Confidenciais. III. A Parte Recebedora não revelará, divulgará, transferirá, cederá, licenciará ou concederá acesso a essas Informações Confidenciais, direta ou indiretamente, a nenhum terceiro, sem o prévio consentimento por escrito da Parte Divulgadora, estando este terceiro, condicionado à assinatura de um Termo de Compromisso de Manutenção de Sigilo prevendo as mesmas condições e obrigações estipuladas neste Termo. IV. A Parte Recebedora informará imediatamente à Parte Divulgadora de qualquer divulgação ou uso não autorizado das Informações Confidenciais da Parte Divulgadora por qualquer pessoa, e tomará todas as medidas necessárias e apropriadas para aplicar o cumprimento das obrigações com a não divulgação e uso limitado das obrigações das empreiteiras e agentes da Parte Recebedora.

120 V. A Parte Recebedora deverá manter procedimentos administrativos adequados à prevenção de extravio ou perda de quaisquer documentos ou Informações Confidenciais, devendo comunicar à Parte Divulgadora, imediatamente, a ocorrência de incidentes desta natureza, o que não excluirá sua responsabilidade. VI. A Parte Recebedora obrigará seu pessoal que possa ter acesso às Informações Confidenciais que cumpram tais obrigações de sigilo, assinando o Termo de Ciência (Anexo L). 5. As Partes se comprometem e se obrigam a tomar todas as medidas necessárias à proteção da informação confidencial da outra Parte, bem como para evitar e prevenir revelação a terceiros, exceto se devidamente autorizado por escrito pela Parte Divulgadora. De qualquer forma, a revelação é permitida para empresas coligadas, assim consideradas as empresas que direta ou indiretamente controlem ou sejam controladas pela Parte neste Termo. Além disso, cada Parte terá direito de revelar a informação a seus funcionários que precisem conhecê-la, para os fins deste Termo; tais funcionários deverão estar devidamente avisados acerca da natureza confidencial de tal informação, e estarão vinculados aos termos e condições do presente Termo de Compromisso de Manutenção de Sigilo independentemente de terem sido avisados do caráter confidencial da informação, ficando a Parte Recebedora responsável perante a Parte Divulgadora por eventual descumprimento do Termo. 6. O intercâmbio de informações nos termos deste instrumento não será interpretado de maneira a constituir uma obrigação de uma das Partes para celebrar qualquer Termo ou acordo de negócio, nem obrigarão a comprar quaisquer produtos ou serviços da outra ou oferecer para a venda quaisquer produtos ou serviços usando ou incorporando as Informações Confidenciais. 7. Cada Parte reconhece que em nenhuma hipótese este Termo será interpretado como forma de transferência de propriedade ou qualquer tipo de direito subsistido nas Informações Confidenciais da parte Divulgadora para a parte Recebedora, exceto o direito limitado para utilizar as Informações Confidenciais conforme estipulado neste Termo. 8. Este Termo entrará em vigor por ocasião da assinatura pelas Partes. Os compromissos deste instrumento também serão obrigatórios às coligadas, subsidiárias ou sucessoras das Partes e continuará a ser obrigatório a elas até a ocasião em que a substância das Informações Confidenciais tenha caído no domínio público sem nenhum descumprimento ou negligência por parte da Parte Recebedora, ou até que a permissão para liberar essas Informações seja especificamente concedida por escrito pela Parte Divulgadora. 9. A omissão ou atraso em aplicar qualquer disposição deste Termo não constituirá uma renúncia de qualquer aplicação futura dessa disposição ou de quaisquer de seus termos. Se qualquer disposição deste Termo, ou sua aplicação, por qualquer razão e em qualquer medida for considerada inválida ou inexequível, o restante deste Termo e a aplicação de tal disposição a outras pessoas e/ou circunstâncias serão interpretados da melhor maneira possível para atingir a intenção das Partes signatárias.

121 10. As Partes concordam que a violação do presente Termo, pelo uso de qualquer Informação Confidencial pertencente à Parte Divulgadora, sem sua devida autorização, causarlhe-á danos e prejuízos irreparáveis, para os quais não existe remédio na lei. Desta forma, a Parte Divulgadora poderá, imediatamente, tomar todas as medidas extrajudiciais e judiciais, inclusive de caráter cautelar, como antecipação de tutela jurisdicional, que julgar cabíveis à defesa de seus direitos. 11. A Parte Recebedora deverá devolver, íntegros e integralmente, todos os documentos a ela fornecidos, inclusive as cópias porventura necessárias, na data estipulada pela Parte Reveladora para entrega, ou quando não mais for necessária a manutenção das Informações Confidenciais, comprometendo-se a não reter quaisquer reproduções (incluindo reproduções magnéticas), cópias ou segundas vias, sob pena de incorrer nas penalidades previstas neste Termo. 12. A Parte Recebedora deverá destruir quaisquer documentos por ela produzidos que contenham Informações Confidenciais da Parte Divulgadora, quando não mais for necessária a manutenção dessas Informações Confidenciais, comprometendo-se a não reter quaisquer reproduções (incluindo reproduções magnéticas), cópias ou segundas vias, sob pena de incorrer nas penalidades prevista neste Termo. 13. A inobservância de quaisquer das disposições de confidencialidade estabelecidas neste Termo sujeitará a Parte infratora, como também o agente causador ou facilitador, por ação ou omissão ou qualquer daqueles relacionados neste Termo, ao pagamento, recomposição, de todas as perdas e danos, comprovadamente suportados ou demonstrados pela outra Parte, bem como as de responsabilidade civil e criminal respectivas, as quais serão apuradas em regular processo, sem prejuízo das demais sanções legais cabíveis, conforme Art. 87 da Lei 8666/ As obrigações de confidencialidade decorrentes do presente Termo, tanto quanto as responsabilidades e obrigações outras derivadas do presente Termo, vigorarão durante o período de 5 (cinco) anos após a divulgação de cada Informação Confidencial à Parte Recebedora. 15. O não exercício por qualquer uma das Partes de direitos assegurados neste instrumento não importará em renúncia aos mesmos, sendo tal ato considerado como mera tolerância para todos os efeitos de direito. 16. Alterações do número, natureza e quantidade das Informações Confidenciais disponibilizadas para a Parte Recebedora não descaracterizarão ou reduzirão o compromisso ou as obrigações pactuadas neste Termo de Compromisso de Manutenção de Sigilo, que permanecerá válido e com todos os efeitos legais em qualquer das situações especificadas neste Termo. 17. O acréscimo, complementação, substituição ou esclarecimento de qualquer das Informações Confidenciais disponibilizadas para a Parte Recebedora, em razão do presente objeto, serão incorporadas a este Termo, passando a fazer dele parte integrante, para todos os fins e efeitos, recebendo também a mesma proteção descrita para as informações iniciais

122 disponibilizadas, não sendo necessário, nessas hipóteses, assinatura ou formalização de Termo Aditivo. 18. Este instrumento não deve ser interpretado como criação ou envolvimento das Partes, ou suas Afiliadas, nem em obrigação de divulgar informações confidenciais para a outra Parte. 19. O fornecimento de Informações Confidenciais pela Parte Divulgadora ou por uma de suas Afiliadas não implica em renúncia, cessão a qualquer título, autorização de uso, alienação ou transferência de nenhum direito, já obtido ou potencial, associado a tais informações, que permanecem como propriedade da Parte Divulgadora ou de suas Afiliadas, para os fins que lhe aprouver. 20. Nenhum direito, licença, direito de exploração de marcas, invenções, direitos autorais, patentes ou direito de propriedade intelectual estão aqui implícitos, incluídos ou concedidos por meio do presente Termo, ou ainda, pela transmissão de Informações Confidenciais entre as Partes. 21. A Contratada declara conhecer todas as Normas, Políticas e Procedimentos de Segurança estabelecidos pelo Contratante para execução do Contrato, tanto nas dependências do Contratante como externamente. 22. A Contratada responsabilizar-se-á integralmente e solidariamente, pelos atos de seus empregados praticados nas dependências do Contratante, ou mesmo fora dele, que venham a causar danos ou colocar em risco o patrimônio do Contratante. 23. Este Termo contém o acordo integral de confidencialidade entre as Partes com relação ao seu objeto. Quaisquer outros acordos, declarações, garantias anteriores ou contemporâneos com relação à proteção das Informações Confidenciais, verbais ou por escrito, serão substituídos por este Termo. Este Termo será aditado somente firmado pelos representantes autorizados de ambas as Partes. 24. Quaisquer controvérsias em decorrência deste Termo serão solucionadas de modo amistoso através do representante legal das Partes, baseando-se nas leis da República Federativa do Brasil. E por estarem assim justas e contratadas, as Partes firmam o presente Instrumento em 03 (três) vias de igual teor e forma, na presença das testemunhas abaixo indicadas. Brasília, de de 20. DE ACORDO CONTRATANTE CONTRATADA <Nome> <Nome> Mat./SIAPE: Mat.: Testemunha 1 Testemunha 2 <Nome> <Nome> Mat./SIAPE: Mat.:

123 Anexo O- MODELO DA PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS PLANILHA DE CUSTOS E FORMAÇÃO DE PREÇOS RESUMO DA PLANILHA DE CUSTOS Quantidade Total MAT Valor Total MAT: R$ Valor Unitário MAT: R$ Tempo de Contratação 12 Meses Definição Recurso: Mão-de- Obra Percentual sobre Remuneração Percentual sobre Custo Final Multiplicador (Nº de Recursos x Vigência) Base Cálculo Valor Final Recurso: Diversos Encargos Sociais Uniforme/Crachá Vale-Transporte Assist. Médica Vale Alimentação Seguro/Auxílio Treinamento/Outros

124 Despesas Administrativas Margem Lucro Impostos CUSTO FINAL 1. Preencher a planilha com os resultados das planilhas unitárias por complexidade/especialização. 2. Efetuar os cálculos de percentuais sobre os custos resultantes 3. Preencher todos os campos, incluindo os que não se aplicam que deverão conter valores ou percentuais iguais a zero. 4. Caso algum insumo não esteja relacionado, incluir na planilha. 5. Os campos Despesas Administrativas e Margem de Lucro, neste Resumo Final, não deverão ser percentuais iguais ou inferiores a Zero.

125 CUSTOS POR ÁREA DE ATIVIDADE / ESPECIALIZAÇÃO Área de Atividade/Especialização: Qtd. Profissionais: Salário Mensal: R$ Tempo de Contratação 12 Meses Definição Percentual sobre Remuneração Percentual sobre Custo Final Multiplicador (Nº de Recursos x Vigência) Base Cálculo Valor Final Recurso: Mão-de-Obra Encargos Sociais Uniforme/Crachá Vale Tranporte Assist. Médica Vale Alimentação Seguro/Auxílio Treinamento/Outros Despesas Administrativas Margem Lucro Custo Final 1. Preencher uma planilha para cada complexidade e/ou grupo de especialização que contenham a mesma remuneração mensal. 2. Preencher todos os campos, incluindo os que não se aplicam que deverão conter valor igual a zero. 3. Caso algum insumo não esteja relacionado, incluir na planilha.

126 Anexo P- PERFIS PROFISSIONAIS E FORMAÇÃO EXIGIDA MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS PERFIS PROFISSIONAIS E FORMAÇÃO EXIGIDA ÁREA DE ATUAÇÃO: ANÁLISE DE ARQUITETURA DE SISTEMAS Perfil: Analista de Arquitetura para Soluções JAVA Formação: Nível superior na área de informática, reconhecido pelo Ministério da Educação, ou formação de nível superior em qualquer área com curso de pós-graduação lato sensu (especialização) na área de informática. Experiência de, no mínimo: 05 (cinco) anos em atividades de desenvolvimento de sistemas de informação; 03 (três) anos em Arquitetura de Sistemas; 02 (dois) anos projetos de integração de sistemas; 02 (dois) anos em Jboss Seam; 02 (dois) anos em Java, J2EE e WebService; 02 (dois) anos em Hibernate, Java Server Faces, Rich Faces, Facelets; 02 (dois) anos em JBoss AS. Cursos e Certificações: Certificação em Sun Certified Java Programmer-SCJP; Certificação em Sun Certified Web Component Developer-SCWCD. Perfil: Analista de Arquitetura para Soluções PHP Formação: Nível superior na área de informática, reconhecido pelo Ministério da Educação, ou formação de nível superior em qualquer área com curso de pós-graduação lato sensu (especialização) na área de informática. Experiência de, no mínimo: 05 (cinco) anos em atividades de desenvolvimento de sistemas de informação; 03 (três) anos em Arquitetura de Sistemas; 02 (dois) anos em projetos de integração de sistemas. 04 (quatro) anos em PHP;

127 02 (dois) anos em JQuery; 02 (dois) anos em Ajax; 02 (dois) anos em Json; 02 (dois) anos em UML; 02 (dois) anos em Oracle ou PostgreSQL ou Microsoft SQL Server ou alguma das seguintes certificações: a) Microsoft Certified IT Professional (MCITP); b) Oracle PL/SQL Developer Certified Associate; 02 (dois) anos em Metodologia Ágil ou RUP ou alguma das seguintes certificações: Cursos e Certificações: c) Scrum Alliance - Scrum Certification (CSM); d) IBM Certified Solution Designer - IBM Rational Unified Process. Certificação em Zend Framework Certification emitido pela Zend; ÁREA DE ATUAÇÃO: ANÁLISE DE NEGÓCIO PARA SISTEMAS Perfil: Analista de Negócio Formação: Nível superior na área de informática, reconhecido pelo Ministério da Educação, ou formação de nível superior em qualquer área com curso de pós-graduação lato sensu (especialização) na área de informática. Experiência de, no mínimo: 07 (sete) anos em TI; 03 (três) anos nas funções de análise de negócio ou gerência de projetos; 01 (um) ano de atividades em projetos com metodologias ágeis; Cursos e Certificações: Certificação PMP- Project Management Professional, concedida pela PMI-Project Management Institute; Certificação CSM- Certified Scrum Master e CSPO- Certified Scrum Product Owner, Scrum Aliance ou PSM I-Professional Scrum Master I, Scrum. Org sendo aceito também em substituição CSP- Certified Scrum Profesional, Scrum Aliance ou PSM II- Professional Scrum Master II, Scrum. Org. Curso, com mínimo de 40 horas, em: a) Processo Unificado; b) ITIL V3- Information Technology Infrastructure Library; c) COBIT- Control Objectives for Information and related Technology; d) BPM- Business Process Management; e) UML- Unified Modeling Language;

128 ÁREA DE ATUAÇÃO: GESTÃO DOS ASPECTOS TÉCNICOS, ADMINISTRATIVOS E LEGAIS DO CONTRATO. Perfil: Preposto Formação: Nível superior completo, reconhecido pelo Ministério da Educação. Experiência de, no mínimo: 01 (um) ano com gestão de contratos e de projetos na Administração Pública ou Privada. Cursos e Certificações: Certificação CSM (Certified Scrum Master), concedida por profissional credenciado pela Scrum Alliance; Certificação PMP concedida pelo PMI.

129 Anexo Q MODELO DO QUADRO DE RECURSOS TÉCNICOS QUADRO DE RECURSOS TÉCNICOS Área de Atividade/Especialização Perfil Carga Horária Remuneração Mensal Quantidade Mínima Analista de Arquitetura para Soluções JAVA ANÁLISE DE ARQUITETURA DE SISTEMAS Analista de Arquitetura para Soluções PHP ANÁLISE DE NEGÓCIO PARA SISTEMAS Analista de Negócio TOTAIS Apresentar, devidamente preenchido, composto dos quantitativos de recursos técnicos que pretende utilizar in loco, distribuídos por áreas de atuação previstas para este TERMO DE REFERÊNCIA, e respectivas remunerações mensais de cada grupo.

130 Anexo R MGDS E GUIAS ADOTADOS PELO INEP MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS MGDS E GUIAS ADOTADOS PELO INEP

131 Diretoria de Tecnologia e Disseminação de Informações Educacionais DTDIE Coordenação-Geral de Sistemas de Informação CGSI Escritório de Projetos - EP Metodologia de Gestão e Desenvolvimento de Sistemas [MGDS 2.0] Brasília, 2011

132 Sumário 1 INTRODUÇÃO Objetivo Aplicação Papéis envolvidos Definições Visão Geral da MGDS FASE DE INICIAÇÃO Detalhamento das Atividades da Fase de Iniciação FASE DE EXECUÇÃO FASE DE ENCERRAMENTO Detalhamento das Atividades da Fase de Encerramento AVALIAR QUALIDADE Homologação Subprocesso Medição de PF Executar Manutenção CONJUNTO DE ARTEFATOS MATERIAL DE APOIO PADRÃO DE NOMENCLATURA E ARMAZENAMENTO DOS ARTEFATOS Metodologia de Gestão e Desenvolvimento de Sistemas 2/61

133 Registro de Mudanças Versão Dt. Versão Responsável Participantes Motivação /09/09 Fábio Divino Equipe CGSI; Criação da metodologia Escritório de Projetos /12/09 Fábio Divino Rosa Medeiros Melhoria na descrição dos processos /01/10 Rosa Medeiros Fábio Divino Melhoria nos fluxos de trabalho e na /04/10 Fábio Divino Escritório de Projetos /10/2010 Rosa Medeiros Núcleo de Métricas; Escritório de Projetos descrição dos processos. 1. Melhoria nos artefatos; 2. Alteração nos processos da Fase de Iniciação; 3. Alteração na composição da equipe de qualidade e de suas atribuições. 1. Detalhamento do processo de medição de pontos de função; 2. Acréscimo do ciclo de vida dos projetos no mapa mental de resumo da MGDS; 3. Inclusão, na descrição do processo de manutenção, do artefato Documentação Técnica da Manutenção; 4. Acréscimo das definições de Alteração de Escopo, Demanda de Desenvolvimento, Demanda de Manutenção, Estória de Usuário e Funcionalidade /12/2010 Fábio Divino 1. Revisão dos capítulos 7 e 8; 2. Inclusão do artefato Estória de Usuários nos processos relacionados à especificação de requisitos /02/2011 Ladjane Arruda Escritório de Projetos. Melhorias e adequação da metodologia mediante fase de transição da FSW e adequação correta ao processo Scrum: 1. Alteração do mapa do processo das fases de Iniciação, Execução, Medição de PF, Encerramento. 2. Alteração do macroprocesso; a. Demandas de projeto de novo sistema e projeto de manutenção serão cobertas pelo processo baseado no Scrum; 3. Alteração do Objetivo da MGDS; 4. Alteração da Aplicação da MGDS; 5. Redefinição da Fase de Iniciação; 6. Redefinição do subprocesso de Medição de PFs; 7. Exclusão do fluxo que contemplava tamanhos de demandas de Manutenção para tratamento da demanda como projeto ou manutenção; 8. Separação de demandas de fluxo unitário Manutenção corretiva; 9. Descrição dos procedimentos das atividades de acordo com o processo Scrum, IN04 e do fluxo contemplado no CCP; 10. Melhoria nas definições de termos, Metodologia de Gestão e Desenvolvimento de Sistemas 3/61

134 tanto quanto ao Scrum quanto ao BPMN; 11. Redefinição e detalhamento da atividade de Detalhar a solicitação junto ao Cliente; 12. Redefinição e detalhamento da atividade Elaborar Backlog ; 13. Redefinição e detalhamento da atividade Avaliar Qualidade ; 14. Redefinição e detalhamento da atividade Realizar Reunião de Planejamento ; 15. Criação da atividade Repassar demanda com a Contratada ; 16. Criação da atividade Tratar nãoconformidades na fase de Iniciação; a. Inclusão do tempo para atendimento da demanda; b. Criação de novo status da OS no CCP para execução e resultado da atividade. 17. Redefinição do subprocesso Medicão de PFs ; 18. Alteração dos responsáveis e participantes da atividade Estimar os PFs da Sprint ; 19. Redefinição e detalhamento da atividade Executar a Sprint ; 20. Exclusão do relatório de status da atividade Executar Sprint ; 21. Exclusão de sistemas (CCP e Inep Demandas), demandas e memória de reunião como resultado/produto de uma atividade; 22. Criação da atividade Tratar não conformidades na fase de Execução ; 23. Exclusão da atividade Realizar testes funcionais e/ou desempenho. Esta atividade foi modificada e absorvida na descrição da atividade Executar Sprint ; 24. Exclusão da atividade Atender demanda de Infraestrutura ou Suporte. Esta atividade foi modificada e absorvida na descrição da atividade Executar Sprint ; 25. Redefinição e detalhamento da atividade Avaliar Qualidade ; 26. Mudança de fluxo após a homologação do cliente na Execução: possibilidade de implantação no ambiente de produção ou não; 27. Retirada da condição no fluxo de Execução OS de garantia? ; 28. Retirada da atividade Formalizar OS do Sprint da fase de Execução; 29. Retirada da atividade Estimar os PFs do Sprint da fase de Metodologia de Gestão e Desenvolvimento de Sistemas 4/61

135 Execução; 30. Retirada da atividade Realizar reunião de planejamento da fase de Execução; 31. Redefinição e detalhamento da atividade Formalizar a Entrega da Sprint (revisão) ; 32. Redefinição e detalhamento da atividade Realizar Reunião de Retrospectiva ; 33. Redefinição e detalhamento da atividade Realizar deploy em produção ; 34. Criação do Subprocesso Avaliar Qualidade ; 35. Criação da atividade Realizar testes de stress ; 36. Criação da atividade Tratar desempenho. 37. Criação da atividade Tratar nãoconformidades stress ; 38. Alteração de definições: Demanda de desenvolvimento e manutenção para demanda projetável e demanda de fluxo unitário; 39. Inclusão do subprocesso de Homologação dentro do prazo da Sprint e homologação tácita do cliente de dois dias úteis; 40. Retirada a pergunta sobre o final do backlog do mapa da fase de Execução; 41. Avaliação da Sprint como artefato obrigatório; 42. Previsão de convite do núcleo de métricas na atividade Elaborar Backlog ; 43. Mudança de nome da atividade Detalhar a Solicitação do Cliente para Construir Visão do Produto. 44. Criação do fluxo Executar Manutenção; 45. Criação da atividade Repassar demanda ; 46. Criação da atividade Executar a manutenção ; 47. Alteração da ordem das atividades Formalizar a entrega da Sprint (revisão) e Avaliar Qualidade. Metodologia de Gestão e Desenvolvimento de Sistemas 5/61

136 Metodologia de Gestão e Desenvolvimento de Sistemas 6/61

137 1 Introdução 1.1 Objetivo Estabelecer uma Metodologia de Gestão e Desenvolvimento de Sistemas (MGDS) que defina um conjunto de processos e uma documentação mínima para as atividades de desenvolvimento e manutenção de sistemas de informação do INEP (Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira). Com esta metodologia espera-se obter um controle de qualidade e um procedimento ordenado de transferência do conhecimento, visando à diminuição da descontinuidade dos trabalhos e dos riscos. Durante a elaboração da MGDS, houve a preocupação em estabelecer-se adequado equilíbrio entre padrões reconhecidos internacionalmente para desenvolvimento de software e gerenciamento de projetos e as necessidades da nossa organização. A MGDS baseia-se na combinação de práticas de Extreme Programming (XP) com o uso da notação UML para a modelagem de sistemas de informação, e das práticas preconizadas pelo Scrum para o gerenciamento de projetos. É importante salientar que as abordagens adotadas como base não são empregadas integralmente, sendo que delas foram selecionados os artefatos e as práticas que melhor se adaptam ao INEP, levando-se em consideração a natureza dos sistemas aqui desenvolvidos e a maturidade deste órgão. A MGDS pode ser comparada a uma caixa de ferramentas, na qual as práticas e artefatos das metodologias/frameworks tradicionais (Open UP, PMBOK e UML) e ágeis (Scrum, XP e Kanban) interagem e são utilizados de forma integrada conforme o contexto do projeto, das equipes e dos fornecedores envolvidos. Essa caixa de ferramentas representa hoje o conjunto de processos que evidencia uma documentação mínima para todos os projetos de desenvolvimento e manutenção de sistemas. Entretanto, temos o framework Scrum como núcleo da nossa metodologia, que como framework incompleto, foi adicionado de componentes de engenharia de software descritos acima. Deve-se ressaltar ainda que a metodologia aqui definida presume uma elaboração progressiva, devendo ser atualizada para refletir o crescimento da maturidade nos processos de desenvolvimento e manutenção de sistemas do INEP. 1.2 Aplicação A MGDS aplica-se tanto a projetos sob responsabilidade das Equipes Internas da Diretoria de Tecnologia e Disseminação de Informações Educacionais (DTDIE), quanto a projetos executados pelas empresas prestadoras de serviços contratadas pelo INEP para atuar nas atividades de desenvolvimento e manutenção de sistemas. 1.3 Papéis envolvidos A DTDIE é composta por duas coordenações: CGSI: Coordenação-Geral de Sistemas de Informação; CGIS: Coordenação-Geral de Infraestrutura e Serviços. Estas coordenações possuem as seguintes áreas / perfis: Analista de Processos do INEP É responsável pelos processos de levantamento de requisitos de negócios e pelo apoio ao Gerente de Projetos do INEP nas atividades de gerenciamento. Este perfil também é responsável pela validação da documentação entregue pela Contratada. Metodologia de Gestão e Desenvolvimento de Sistemas 7/61

138 Analista de Testes e Qualidade do INEP É responsável pelos processos relacionados a testes de aceitação e a garantia da qualidade do código fonte entregue pela contratada. Área de Infraestrutura do INEP Área subordinada à CGIS é composta pelos perfis: Administrador de Banco de Dados, Administrador de Dados, Gerente de Telecomunicações, Gerente de Segurança, Administrador de Redes e Analista de Segurança. Esta área é responsável por todas as atividades relacionadas à Infraestrutura de TI. Área de Qualidade do INEP Área subordinada à CGSI é composta pelos perfis: Analista de Teste e Qualidade do Inep e Arquiteto de Sistemas do Inep. Esta área é responsável pelos processos de garantia da qualidade dos produtos entregues pela contratada. Área de Suporte do INEP Área subordinada à CGIS é composta por um Gerente de Suporte e técnicos de informática. Esta área é responsável pelo atendimento às demandas dos usuários relacionadas a suporte de informática. Arquiteto de Sistemas do INEP É responsável pelos processos relacionados à definição da arquitetura do sistema a ser desenvolvido e pela garantia da qualidade do código fonte entregue pela contratada. Gerente de Projetos do INEP É responsável por gerenciar os projetos de desenvolvimento e manutenção de sistemas de informação. Gestor do Contrato no INEP É responsável pela abertura e encerramento das Ordens de Serviço, atividades nas quais é auxiliado pelo Gerente de Projetos do Inep. Especialista em Pontos de Função Profissional certificado em pontos de função pelo IFPUG (CFPS). Participa nos processos de contagem e conferência em pontos de função. Também é previsto pela metodologia que a contratada tenha profissional com este mesmo perfil. Além das áreas/perfis mencionados temos também os seguintes pápeis envolvidos na metodologia: Contratada Empresa contratada para prestação de serviços de desenvolvimento e manutenção de sistemas de informação. Este papel é desempenhado pelo Preposto da Contratada e seus técnicos. Cliente Representante de uma das áreas de negócio do INEP ou do MEC. É responsável pela solicitação e aceite dos serviços de desenvolvimento e de manutenção de sistemas de informação. 1.4 Definições Alteração de Escopo é a mudança solicitada pelo cliente durante a execução de atividades de desenvolvimento de um novo sistema ou de manutenção em um sistema existente. Sempre que houver alteração em um requisito durante um projeto de desenvolvimento ou uma manutenção, o Gerente de Projetos/Product Owner poderá acomodar a mudança da funcionalidade durante o Metodologia de Gestão e Desenvolvimento de Sistemas 8/61

139 sprint atual ou no backlog do produto, para que seja executada em uma iteração (sprint) posterior. Ator alguém ou alguma coisa que interage com um sistema para atingir um determinado objetivo. Exemplos: usuários, outros sistemas, planilhas manipuladas pelo sistema, etc; Backlog é a coleção de funcionalidades definidas pelo cliente e que geram valor para o negócio; Caso de uso seqüência de ações que um sistema executa, de forma a gerar um resultado de valor para o usuário; Caso de teste Documentação que especifica entradas, resultados previstos e condições de execução de um conjunto de testes; CCP Sistema de Controle de Contratos e Projetos; Demanda projetável é caracterizada pela necessidade de construção de um novo sistema ou de manutenção (de melhoria ou evolução) que possa ser caracterizada como um projeto. Ou seja, as demandas serão planejadas, executadas e controladas para criação de um produto, serviço ou resultado exclusivo; Demanda de fluxo unitário é caracterizada pela necessidade de correção ou melhoria de um sistema que esteja homologado ou em produção. Pode ser acréscimo de funcionalidades novas ou alteração/exclusão de funcionalidades existentes; Especificação de caso de uso especificação textual de cada caso de uso, representada através de fluxos de eventos. A especificação do caso de uso apresenta, de forma seqüencial, o diálogo entre o ator e o sistema; História de Usuário é a menor unidade de funcionalidade que possui valor para o usuário. Uma história é composta por três partes: uma descrição por escrito, utilizada para planejamento ou como lembrete; conversas, que têm por objetivo detalhar a estória; e testes, que podem ser utilizados para determinar quando a estória estará completa; Funcionalidade é a menor parte de uma operação em um sistema, que possua valor para um usuário. É uma história de usuário conforme definido pelo framework XP e que, para o Processo Unificado, seria equivalente à decomposição de um caso de uso ou mesmo à descrição do cenário de um caso de uso; Kanban É uma abordagem Lean para o desenvolvimento ágil de software. Como ferramenta de processo, o Kanban é considerado menos prescritivo do que o Scrum. Nesta metodologia, utilizaremos o Kanban para administração de sistemas, ou seja, manutenções de software; Lean É uma prática de produção que considera o gasto de recursos para qualquer outro objetivo que não a criação de valor para o cliente final como um desperdício, e, portanto, um alvo para a eliminação; Modelo de dados representação gráfica da estrutura e do relacionamento das tabelas de um sistema de informação; PFs Pontos de Função; OS Ordem de Serviço; Sistema de Demandas sistema de gestão de demandas do Inep, atualmente chamado de Simec Demandas; Subversion também conhecido por SVN, aplicativo utilizado no INEP para armazenamento e controle de versões de documentos e código-fonte; Sistema de Controle de Contratos e Projetos (CCP) sistema de gestão de contratos e projetos do Inep; Scrum É uma abordagem ágil para o gerenciamento de projetos. Fornece práticas que ajudam gerentes a tornar mais dinâmico e gerenciável o ambiente de desenvolvimento de software; Metodologia de Gestão e Desenvolvimento de Sistemas 9/61

140 Sprint representa uma iteração no processo de desenvolvimento de software, na qual o time do projeto irá produzir uma parte do sistema definida pelo cliente. O conceito de Sprint nos remete à necessidade de estarmos freqüentemente entregando algo de valor para o cliente. Diferentemente dos modelos tradicionais, onde você desenvolve o produto em um longo período de tempo e, apenas no final com o produto pronto - o entrega ao cliente, em Scrum você sempre entregará parte do produto em pequenos intervalos de tempo, sendo que esta parte é a prioridade do cliente, ou seja, o que ele realmente está precisando naquele momento; Backlog do Sprint é um subconjunto do Backlog, priorizado na reunião de planejamento pelo cliente e que representa as funcionalidades que serão desenvolvidas em um determinado Sprint; Reunião de planejamento do Sprint reunião realizada no início do Sprint, para planejar e definir o que será entregue; Reunião de retrospectiva do Sprint reunião realizada no fim de cada Sprint, para registrar as lições aprendidas e fazer os ajustes possíveis para o próximo, proporcionando assim a melhoria contínua do processo; Reunião de Revisão do Sprint o objetivo da reunião é apresentar o que a equipe realizou durante o Sprint e avaliar a necessidade de homologação; TI Tecnologia da Informação; XP (extreme Programming) É uma abordagem ágil para a engenharia de projetos de software. Como o próprio nome diz, é extremamente focada no desenvolvimento, e tem como principal característica a programação em par. 1.5 Visão Geral da MGDS A Metodologia de Gestão e Desenvolvimento de Sistemas MGDS é composta por três fases que abrangem o ciclo de vida do projeto (demanda projetável) Iniciação, Execução e Encerramento - e por duas etapas que abrangem o tratamento de manutenção de sistemas (fluxo unitário) Executar Manutenção e Encerramento. Estas fases e etapas são compostas por atividades e subprocessos. Abaixo é apresentado um diagrama que descreve a MGDS de forma macro. Metodologia de Gestão e Desenvolvimento de Sistemas 10/61

141 Nos próximos tópicos, cada fase ou etapa e seus respectivos subprocessos e atividades serão descritos pela seguinte taxonomia: Nome da atividade; Finalidade; Responsável; Participantes; Insumos; Produtos/Resultados; Descrição das atividades do processo; Observação: a fase de iniciação poderá ser realizada pela equipe do Inep ou pela Contratada. A fase de execução sempre será de responsabilidade da Contratada e a fase de Encerramento sempre será de responsabilidade da equipe do Inep. Metodologia de Gestão e Desenvolvimento de Sistemas 11/61

142 2 Fase de Iniciação Metodologia de Gestão e Desenvolvimento de Sistemas 12/61

143 Detalhamento das Atividades da Fase de Iniciação Início da Fase de Iniciação A fase de iniciação começa quando um Gerente de Projetos do Inep (Product Owner) recebe uma solicitação da área cliente, de projeto desenvolvimento de novo sistema ou projeto de manutenção (demanda projetável). O Gerente de Projetos do Inep analisa a necessidade do cliente. Posteriormente, o Gerente de Projetos do Inep analisa a possibilidade de sua equipe interna realizar o detalhamento junto ao Cliente ou de solicitar os serviços da Contratada, decidindo quem será responsável pelo detalhamento da demanda. Caso o responsável pelo detalhamento da demanda (fase de iniciação) venha a ser a Contratada, será aberta uma OS específica para esta fase através da atividade Elaborar OS de Iniciação. Caso o responsável pelo detalhamento da demanda seja a equipe interna, o fluxo segue para a atividade Construir a visão do produto. Elaborar OS de iniciação Finalidade Responsável Participantes Insumos Produtos/Resultados Gerar OS da demanda da fase de Iniciação. Gerente de Projetos do Inep (Product Owner). Contratada; Gestor do Contrato no Inep. Solicitação recebida da área cliente. Ordem de Serviço da fase de iniciação com status Emitida. O Gerente de Projetos do Inep (Product Owner) cadastra a demanda de desenvolvimento de novo sistema ou de projeto de manutenção no sistema de Controle de Contratos e Projetos do Inep (CCP). A OS fica com o status de Em Elaboração. O Gestor do Contrato emite oficialmente a OS, autorizando a Contratada a realizar o detalhamento da demanda junto ao Cliente. A OS fica com status de Emitida. A Contratada poderá aceitar ou rejeitar a OS, mediante justificativa plausível e aderente ao contrato. Com a OS aceita e seu status alterado para Em andamento, o fluxo segue para a atividade Construir a visão do produto. Construir a visão do produto Finalidade Responsável Participantes Detalhar a demanda do projeto de desenvolvimento de um novo sistema ou projeto de manutenção, com intuito de levantar as necessidades do Cliente para construção da Visão do Produto. Gerente de Projetos do Inep (Product Owner). Cliente; Analista de Processos do Inep; Analistas de Testes e Qualidade de Software do Inep; Metodologia de Gestão e Desenvolvimento de Sistemas 13/61

144 Insumos Produtos/Resultados Contratada. Solicitação registrada no Sistema de Demandas; Ordem de Serviço da fase de iniciação com status Em Andamento (se a Contratada for a executora por esta fase); Guia de Arquitetura; Guia de Desenvolvimento de Sistemas; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas; Ferramentas e Técnicas do Scrum; Subversion. Roadmap; Documento de Visão; Documento de Arquitetura do Projeto; Modelo Sintético de Casos de Uso; Modelo de Dados (versão preliminar). O papel responsável por esta atividade é do Gerente de Projetos do Inep (Product Owner), que poderá ser auxiliado por um Analista de Processos do Inep (no papel de analista de negócios) e por um Administrador de Dados do Inep. Caso a Contratada execute a fase de Iniciação, esta fará as atividades do papel de analista de negócio, realizando o levantamento das necessidades negociais do cliente, sempre acompanhada do Gerente de projetos do Inep (Product Owner) e entregando os artefatos obrigatórios (descritos na MGDS) e os solicitados na OS. O responsável pela execução realiza quantas reuniões forem necessárias com os participantes envolvidos até que seja possível definir a Visão do Produto (de novo sistema ou projeto de manutenção). O Roadmap poderá ser desenvolvido caso o Product Owner julgue necessário. Os Analistas de Testes e Qualidade podem ser convidados para acompanhar a atividade. Nesta atividade, deverá ser estabelecida a definição de pronto. Ou seja, critérios (qualidade) que as entregas das Sprints de execução deverão atender para o aceite do Product Owner. É recomendável que um Administrador de Dados do Inep participe das reuniões onde o modelo de dados do projeto seja trabalhado. Neste caso, o responsável deverá alinhar a demanda com o grupo de analistas de dados. Em seguida, os artefatos previstos na OS serão elaborados\atualizados pelo seu executor (Contratada ou Equipe interna), criando/atualizando, no Subversion, a estrutura de documentos do projeto, armazenando nessa estrutura os artefatos criados ou alterados durante todo o processo (de acordo com o padrão de nomenclatura e armazenamento dos artefatos previsto na MGDS). Caso esta atividade seja executada pela Contratada, esta deverá informar ao Gerente de Projetos (Product Owner) a URL no svn onde estão localizados os artefatos criados/atualizados. O fluxo segue para a atividade Elaborar Backlog. Elaborar o backlog Finalidade Responsável Participantes Priorizar a lista de funcionalidades a ser entregue pelo projeto, detalhar as funcionalidades mais prioritárias e realizar o planejamento das entregas em produção. Gerente de Projetos do Inep (Product Owner). Cliente; Analista de Processos do Inep; Metodologia de Gestão e Desenvolvimento de Sistemas 14/61

145 Insumos Produtos/Resultados Administrador de Dados do Inep; Analistas de Testes e Qualidade de Software do Inep; Núcleo de métricas; Designer; Contratada. Ordem de Serviço da fase de iniciação com status Em Andamento (se a Contratada for a executora desta fase); Ferramentas e Técnicas do Scrum; Subversion; Documento de Visão; Documento de Arquitetura do Projeto; Modelo Sintético de Casos de Uso; Modelo de Dados (versão preliminar); Guia de Arquitetura; Guia de Desenvolvimento de Sistemas; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas. Ordem de Serviço da fase de iniciação com status Execução Finalizada (se a Contratada for a executora desta fase); Documento de Visão; Backlog; Especificação de caso de uso ou histórias de usuário; Casos de Teste; Protótipo; Modelo de Dados; Aceite do Cliente na OS de Iniciação (caso a contratada execute essa fase). O Gerente de Projetos do Inep (Product Owner) cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do produto seja atingida. Esta lista é o Backlog. Ou seja, a lista contém os requisitos do produto que o Time Scrum (Contratada) vai desenvolver ou está desenvolvendo. Este artefato nunca está completo, ele evolui à medida que o produto em si e o ambiente em que o Backlog está sendo usado se desenvolve. Ele é dinâmico no sentido de que ele está constantemente mudando para identificar o que o produto precisa para ser apropriado e útil. O responsável revisa o Backlog e, em conjunto com o cliente, prioriza as funcionalidades. Cada novo requisito é priorizado, inserido, ou removido do Backlog pelo Gerente de Projetos do Inep (Product Owner) a qualquer momento. Nesta atividade, os envolvidos deverão esboçar as metas mais prioritárias do negócio e que deverão ser atendidas nas próximas sprints ou próximo release. Depois, detalham-se os itens com a finalidade de construção das histórias de usuário ou dos casos de uso, e na elaboração dos protótipos de interface com o usuário. Os requisitos deverão estar detalhados o suficiente (ready) para repasse ao time na reunião de planejamento. A decisão pelo uso de histórias ou casos de uso fica a critério do Gerente de Projetos do Inep (Product Owner). Entretanto, a cada Iniciação, pelo menos um requisito do Backlog deverá ser detalhado em histórias ou casos de uso. Obviamente, os mais prioritários. Devem ser construídos quantos protótipos de interface forem necessários para o completo entendimento do negócio. Se a decisão for pelo uso de histórias de usuário, os protótipos deverão acompanhar o texto da história. O designer poderá ser convidado para dirimir dúvidas a respeito dos padrões de interface. Os Analistas de Testes e Qualidade podem ser convidados para acompanhar a atividade. Metodologia de Gestão e Desenvolvimento de Sistemas 15/61

146 O núcleo de métricas poderá ser convidado para tomar ciência sobre os requisitos que estão sendo especificados, com o intuito de dar mais agilidade ao processo de validação das contagens resultantes desses requisitos. Caso a Iniciação esteja sendo executada pela Contratada, o Administrador de Dados do Inep direciona a modelagem de dados, visando melhor consistência do negócio, aderência aos padrões do Inep e utilização eficiente dos modelos corporativos, orientando o administrador de dados da contratada no desenvolvimento do modelo de dados. Caso a execução esteja sendo executada pelo Inep, o administrador de dados do Inep deverá conduzir a análise e modelagem dos dados. A Visão do produto deverá estar sempre em evidência, pois esta é o objeto de aceite e satisfação ao fim do projeto. Eventualmente, poderá ser refinada. Ao final da atividade, caso a Iniciação esteja sendo executada pela Contratada: O Gerente de Projetos do Inep (Product Owner) valida o escopo com o cliente, adquirindo o aceite da OS; A Contratada finaliza a execução da OS; O status da OS será Execução Finalizada ; O fluxo segue para a atividade Avaliar a Qualidade. Caso a Iniciação esteja sendo executada pelo Inep, o fluxo segue para a atividade Repassar a Demanda com a Contratada. Avaliar a qualidade Finalidade Responsável Participantes Insumos Avaliar a documentação produzida na Fase de Iniciação pela Contratada, com foco na garantia da qualidade desta documentação. Gerente de Projetos do Inep; Contratada Analista de Processos do Inep; Arquiteto de Sistemas do Inep; Analista de Testes; Administrador de Dados do Inep; Área de Infraestrutura do Inep. Ordem de Serviço da fase de iniciação com status Execução Finalizada ou Ordem de Serviço da fase de iniciação com status Não-conformidade Finalizada. Documento de Visão; Documento de Arquitetura do Projeto; Guia de Escrita de Caso de Uso do INEP; Modelo Sintético de Casos de Uso; Especificação de Caso de Uso ou Histórias de Usuário; Protótipo; Modelo de Dados (com dicionário de dados); Guia de Arquitetura; Guia de Desenvolvimento de Sistemas; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas. Metodologia de Gestão e Desenvolvimento de Sistemas 16/61

147 Produtos/Resultados Documentação homologada pela área de TI; ou Lista de não-conformidades encontradas. Ordem de Serviço da fase de iniciação com status Conforme ou Nãoconforme ); Gerente de Projetos do Inep (Product Owner) verifica se os documentos solicitados na OS ou apontados na lista de não-conformidades foram entregues. Caso todos os documentos solicitados forem entregues pela contratada, realizar os seguintes procedimentos: Gerente de Projetos do Inep(Product Owner) abre uma demanda no sistema Inep demandas, encaminhando às devidas áreas competentes, com a finalidade de verificação à luz dos padrões definidos pelo Inep e aderência ao negócio (escopo previsto no projeto), os seus respectivos artefatos. Ex: documento de arquitetura do projeto para a equipe de arquitetura da linguagem correspondente; documento de Visão, história do usuário ou casos de uso para a equipe de análise de requisito do projeto (caso exista), casos de teste para a equipe de testes e qualidade do Inep, modelo de dados para a equipe de administrador de dados do Inep. Após o tempo acordado para a homologação, o Gerente de Projetos do Inep(Product Owner) receberá o feedback das equipes responsáveis; Caso todos os documentos solicitados na OS não forem entregues ou não-conformidades sejam encontradas, o Gerente de Projetos do Inep (Product Owner) informa a(s) não-conformidade(s) no CCP e o fluxo é direcionado para a atividade Tratar não-conformidades para as correções necessárias. A OS ficará com o status de Não-conforme. Caso contrário, o Gerente de Projetos do Inep homologa a documentação da fase de Iniciação e o fluxo segue para a atividade Estimar os PFs da Demanda. Desta forma, a OS ficará com o status de Conforme. Tratar não-conformidades Finalidade Responsável Participantes Insumos Produtos/Resultados Corrigir não-conformidades encontradas na atividade Avaliar qualidade. Contratada Analista de Processos do Inep; Gerente de Projetos do Inep. Ordem de Serviço da fase de iniciação com status Não-conforme ; Lista de não-conformidades encontradas; Documento de Visão; Documento de Arquitetura do Projeto; Guia de Escrita de Caso de Uso do INEP; Modelo Sintético de Casos de Uso; Especificação de Caso de Uso ou Histórias de Usuário; Protótipo; Modelo de Dados; Guia de Arquitetura; Guia de Desenvolvimento de Sistemas; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas. Lista de não-conformidades encontrada atualizada; Artefatos atualizados; Ordem de Serviço da fase de Iniciação com status Não-conformidade Metodologia de Gestão e Desenvolvimento de Sistemas 17/61

148 Finalizada. A Contratada recebe a lista de não-conformidades via CCP e deverá tratá-las em observância ao prazo estipulado no contrato de desenvolvimento e manutenção de sistemas vigente 48 horas. Durante esta atividade, o status da OS ficará como Tratando não-conformidade. Após a conclusão da atividade, a Contratada deverá liberar a OS para nova avaliação da qualidade. Desta forma, a OS terá seu status alterado para Ordem de Serviço da fase de iniciação com status Não-conformidade Finalizada e o fluxo segue para a atividade Avaliar a qualidade. Estimar os PFs da demanda Finalidade Responsável Participantes Insumos Produtos/Resultados Estimar o tamanho da demanda de projeto de desenvolvimento de novo sistema ou projeto de manutenção em sistema existente. Contratada. Especialista em pontos de função da Contratada. Ordem de Serviço da fase de iniciação com status Conforme ; Guia de Contagem de Pontos de Função do Inep; Documento de Visão; Documento de Arquitetura do Projeto; Modelo Sintético de Casos de Uso; Modelo de Dados; Especificação de caso de uso ou histórias de usuário; Protótipo. Planilha de contagem estimativa de pontos de função da demanda. O responsável estima os pontos de função da demanda conforme previsto no Guia de Contagem de Pontos de Função do Inep, documentando-a no modelo apropriado, disponível nesta MGDS. Ao final da atividade, o fluxo segue para o subprocesso Medição de PF - a planilha de pontos de função segue para validação dos pontos de função envolvidos na fase de iniciação. Com os PFs da fase de iniciação aceitos, o subprocesso Encerramento da OS (fase de Encerramento) é executado e, paralelamente, o fluxo segue para a atividade Realizar reunião de planejamento. Repassar a Demanda com a Contratada Finalidade Responsável Participantes Insumos Alinhar o entendimento do negócio demandado entre Inep e Contratada. Gerente de Projetos do Inep. Analista de Processos do Inep; Administrador de Dados do Inep; Contratada. Backlog; Documento de Visão; Documento de Arquitetura do Projeto; Metodologia de Gestão e Desenvolvimento de Sistemas 18/61

149 Produtos/Resultados Modelo Sintético de Casos de Uso; Roadmap; Especificação de Caso de Uso ou Histórias de Usuário; Protótipo; Modelo de Dados. Alinhamento sobre os requisitos candidatos à próxima execução da Sprint. Os participantes alinham o entendimento sobre as funcionalidades mais prioritárias do Backlog e que provavelmente serão incluídas na próxima Sprint. Essa atividade tem a finalidade de proporcionar à Contratada um melhor planejamento no atendimento da demanda e alinhamento dos artefatos que deverão estar como preparados (ready) para a fase de execução. Realizar reunião de planejamento Finalidade Responsável Realizar o planejamento da iteração (Sprint) a ser executada. Gerente de Projetos do Inep (Product Owner). Participantes Insumos Contratada; Cliente; Arquiteto de Sistemas do Inep; Analistas de testes do Inep; Área de Infraestrutura do Inep. Backlog (priorizado); Documento de Visão; Documento de Arquitetura do Projeto; Modelo Sintético de Casos de Uso; Roadmap; Especificação de caso de uso ou histórias de usuário; Protótipo; Modelo de Dados; Ferramentas e Técnicas do Scrum Anotações com os resultados da Sprint Review passada; Agenda da próxima Sprint pronta: data inicial e final, anotações, impedimentos previstos, etc. Produtos/Resultados Backlog da Sprint; Iteração criada no CCP; Backlog atualizado. Os itens devem estar detalhados até o ponto em que estejam preparados (ready) para entrar em uma reunião de planejamento da Sprint, ou seja, atendendo aos critérios de qualidade definidos pelo Product Owner. É nesta atividade que a iteração (Sprint) é planejada. É contabilizada como tendo 8 horas de duração para uma Sprint de 1(um) mês. Para Sprints mais curtos, aloca-se aproximadamente 5% do tamanho total da Sprint para essa reunião, e esta consiste de 2 (duas) partes. A primeira parte, um time Box de 4 horas, é quando é decidido o que será feito na Sprint. A segunda parte, outro time Box de 4 horas, é quando o time (Contratada) decide como construirá essa funcionalidade em um incremento do produto Metodologia de Gestão e Desenvolvimento de Sistemas 19/61

150 durante essa Sprint. O Product Owner deve falar ao time da Contratada sobre a visão do produto e apresentar os itens de maior prioridade do backlog. Os participantes selecionam, no backlog, o conjunto de funcionalidades a ser entregue pela iteração (Sprint). Essas funcionalidades irão compor o backlog da sprint. Tendo selecionado os itens do backlog, a Meta da Sprint é delineada. A Meta é uma descrição que fornece orientação ao Time da Contratada sobre a razão pela qual ele está produzindo o incremento. Durante esta parte da reunião, o Product Owner pode realizar alterações de inclusão, exclusão ou alteração do backlog e também alinhar com o Time a definição de pronto ( done ) para a próxima Sprint. O Time da Contratada deve realizar a estimativa dos itens do backlog caso não estejam estimados. Na segunda parte da reunião, a Contratada trata a questão do como?, ou seja, o seu Time decide como transformará os itens selecionados do backlog, que foi definido na parte anterior da reunião, em um incremento pronto e implementado. Usualmente, o Time começa projetando o trabalho e identificando tarefas, que são peças detalhadas do trabalho necessário para converter o backlog em software funcional. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Backlog. O Product Owner está presente nesta parte da reunião para esclarecer dúvidas sobre os itens do backlog e para ajudar a efetuar mudanças, caso estas sejam necessárias. Outras pessoas podem ser convocadas para a reunião (ex: arquiteto de sistemas, administrador de dados, gerente de redes, analistas de testes, etc) para fornecer conselho técnico ou específico do domínio em questão. O planejamento da sprint será cadastrado no sistema CCP como uma iteração. O fluxo segue para a atividade Estimar os PFs da Sprint. NOTAS: O prazo de entrega corresponde ao período de tempo que a Contratada tem para executar a Sprint, realizar os testes funcionais e/ou de desempenho e elaborar o procedimento de implantação. Esse prazo nunca poderá ser superior a 4 semanas. O ideal é entre 2 a 4 semanas. Estimar os PFs da Sprint Finalidade Responsável Participantes Insumos Produtos/Resultados Estimar o tamanho da iteração (Sprint) a ser entregue. Núcleo de Métricas do Inep (especialista em pontos de função). Gerente de Projetos do Inep (Product Owner); Analista de Processos do Inep. Guia de Contagem de Pontos de Função do Inep; Backlog do Sprint; Protótipo; Documento de Visão; Modelo Sintético de Casos de Uso; Modelo de Dados; Iteração criada no CCP; Especificação de Caso de Uso ou Estórias de Usuário. Planilha de contagem estimativa de pontos de função da iteração (sprint). Metodologia de Gestão e Desenvolvimento de Sistemas 20/61

151 Caso a fase de Iniciação seja executada pela equipe interna do Inep, o responsável estima os pontos de função da demanda que irá ser executada na próxima Sprint, conforme previsto no Guia de Contagem de Pontos de Função do Inep, documentando-a no modelo apropriado, disponível nesta MGDS. Caso a fase de Iniciação seja executada pela Contratada, o responsável selecionará na contagem realizada em Estimar os PFs da demanda o equivalente ao Sprint Backlog que será executado. Em ambos os casos supracitados, o participantes poderão ser requisitados para auxiliar no entendimento dos requisitos, como também na contagem dos PFs. O fluxo segue para a atividade Elaborar OS da Sprint. Elaborar OS da Sprint Finalidade Responsável Participantes Insumos Produtos/Resultados Elaborar e autorizar a Contratada a executar as funcionalidades listadas no Backlog da Sprint. Gerente de Projetos do Inep (Product Owner). Gestor do Contrato no Inep; Analista de Processos do Inep; Contratada. Backlog da Sprint; Planilha de contagem estimativa de pontos de função da iteração (Sprint). Ordem de Serviço da Sprint com status Emitida. O Gerente de Projetos do Inep (Product Owner) elabora a OS da Sprint. O Gestor do Contrato no Inep emite a Ordem de Serviço, autorizando a Contratada a executar as funcionalidades listadas no backlog da Sprint. O fluxo segue conforme previsto no subprocesso Execução da Sprint, detalhado adiante neste documento. NOTA: O prazo para entrega da Sprint para a Avaliação da Qualidade é definido neste processo. Metodologia de Gestão e Desenvolvimento de Sistemas 21/61

152 3 Fase de Execução Metodologia de Gestão e Desenvolvimento de Sistemas 22/61

153 Detalhamento das Atividades de Desenvolvimento de Sistemas Início do processo O processo começa quando a Contratada recebe a Ordem de Serviço autorizando a execução de uma iteração (sprint) para entregar um subconjunto de funcionalidades de um projeto de desenvolvimento de novo sistema ou de um projeto de manutenção. O fluxo segue para o processo Executar a Sprint. Executar a Sprint Finalidade Responsável Participantes Insumos Produtos/Resultados Executar todas as atividades necessárias à entrega do conjunto de funcionalidades listadas no Backlog da Sprint. Contratada. Cliente; Gerente de Projetos do Inep (Product Owner); Analista de Processos do Inep; Arquiteto de Sistemas do Inep; Área de Suporte do Inep; Área de Infraestrutura do Inep. Backlog da Sprint; Ordem de Serviço da fase de Execução com status Em Andamento ; Documento de Visão; Documento de Arquitetura do Projeto; Modelo de Dados; Especificações de Casos de Uso ou Estórias de Usuário; Protótipo; Guia de Arquitetura; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas; Guia de Desenvolvimento de Sistemas; Ferramentas e Técnicas do Scrum; Técnicas do XP; Subversion. Ordem de Serviço da fase de Execução com status Execução Finalizada ; Documento de Arquitetura do Projeto atualizado; Diagrama de Classes (se for o caso); Modelo de Dados e scripts; Casos de Teste (atualizado); Especificações de Casos de Uso ou Estórias de Usuário; Protótipo; Código-fonte e testes unitários; Relatório de Cobertura de Testes; Scripts dos testes funcionais; Resultados dos Testes; Procedimento de Implantação; Demais produtos pertinentes. Metodologia de Gestão e Desenvolvimento de Sistemas 23/61

154 O Scrum-Master deverá facilitar o trabalho do Time, removendo os impedimentos encontrados e garantindo a boa aplicação do Scrum e, conseqüentemente, da MGDS. Durante a Sprint, o Time poderá sentir necessidade de consultar o Gerente de Projetos do Inep (Product Owner). Como também, recomenda-se apresentá-lo às funcionalidades conforme seu desenvolvimento. O Gerente de Projetos do Inep (Product Owner) deverá estar sempre disponível. Os itens e suas tarefas deverão ser tratados por prioridade, ou seja, obedecendo as prioridades definidas no Backlog. Os Times deverão ser auto-organizáveis, multi-disciplinares, comprometidos, focados na meta da Sprint e comunicativos. Diariamente, deverá haver uma reunião de 15 minutos (Daily Meeting) na qual cada membro responderá: O que fez desde a última reunião? O que pretende fazer até a próxima? Se houve, ou há algum impedimento? Esta reunião tem como objetivo dar visibilidade ao Time de como está o caminho para a meta da Sprint. O Time deverá aplicar as boas práticas de engenharia de software para garantir a qualidade do produto que está sendo entregue, conforme os guias de Desenvolvimento de Sistemas, de Arquitetura, de Banco de Dados e de Segurança da Informação para Desenvolvimento de Sistemas. Algumas boas práticas de engenharia de software são: refactoring, testes unitários, desenvolvimento dirigido por testes, inspeção de código, integração contínua, padrões de projeto,etc. Durante a atividade, a Contratada deverá observar os seguintes pontos: Elaboração/atualização de todos os artefatos previstos na Ordem de Serviço e outros documentos gerados; Aplicação das boas práticas de engenharia de software, como a geração de código-fonte e testes unitários em conformidade com os guias disponibilizados como insumos neste processo; A qualquer momento, se houver necessidade de serviços de infraestrutura (alteração no modelo de dados, por exemplo) ou de suporte, a Contratada registra uma demanda no Sistema de Demandas, sempre dando ciência ao Product Owner; Realizar testes funcionais conforme o desenvolvimento das funcionalidades da Sprint (itens da Sprint backlog); Seguir os Procedimentos e Checklists publicados no Demais atividades necessárias à perfeita construção e entrega do sprint. Ao final da atividade, a Contratada deverá: Emitir Relatório de Cobertura de Testes e Evidências de Testes após término da codificação. Seguir os Procedimentos e Checklists publicados no (Procedimentos de Testes, Utilizando o SVN e INEP Demandas) para disponibilizar o código com fins de avaliação da qualidade pela equipe de Testes e Qualidade de Software do Inep; Documentar, conforme modelo fornecido pelo Inep, o procedimento que viabilizará a implantação dos produtos gerados pela Sprint atual nos ambientes de homologação e de produção. Registrar uma demanda no INEP Demandas, solicitando o deploy no ambiente de homologação. Nesta demanda é referenciado o conteúdo da implantação, que deverá estar disponível no SVN, e anexado o artefato Procedimento de Implantação. Metodologia de Gestão e Desenvolvimento de Sistemas 24/61

155 Finalizar a execução da OS, que ficará com status de Execução Finalizada. O fluxo segue para o subprocesso Avaliar Qualidade, onde o produto será homologado pela área de TI e a OS deverá sair com o com status Conforme, que se tornam insumos da atividade Formalizar a entrega da Sprint (reunião de revisão). NOTA: O prazo de entrega do produto para a recebimento provisório finaliza nesta atividade. Formalizar a entrega da Sprint (reunião de revisão) Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar reunião para formalizar a entrega das funcionalidades desenvolvidas durante a execução do sprint. Contratada. Gerente de Projetos do Inep (Product Owner); Analista de Processos do Inep; Analistas de Testes e Qualidade de Software do Inep (opcional); Administrador de Dados (opcional); Arquitetos de software (opcional). Ordem de Serviço da fase de Execução com status Execução Finalizada ; Backlog da Sprint; Ferramentas e Técnicas do Scrum. Produto analisado segundo critérios de aceitação. A reunião de revisão (Sprint Review Meeting) é uma apresentação do resultado da Sprint para o Product Owner, com o propósito de fornecer transparência e realizar a inspeção e adaptação. É uma reunião de 4 horas para Sprints de um mês. Para Sprints de menor duração, essa reunião não deve tomar mais do que 5% do Sprint total. O Gerente de Projetos do Inep lidera a reunião e avalia, em conjunto com os participantes, se as entregas acordadas para a Sprint foram efetivamente realizadas, ou seja, só devem ser aceitos os produtos que satisfaçam a definição de pronto (Done) e que atendam aos critérios de aceite, caso estes tenham sito definidos. O Time discute o que ocorreu bem durante a Sprint e quais problemas foram enfrentados, assim como esses problemas foram resolvidos. O Time então demonstra o trabalho que foi feito (através de uma demo do software) e responde a questionamentos do P.O. O P.O discute o estado atual do Backlog e o grupo inteiro colabora mediante o exposto e o que isso significa com relação ao que fazer nas próximas reuniões de planejamento. Possíveis ações decorrentes desta reunião: Devolver ao Backlog funcionalidades não terminadas (que foram previamente acordadas com o P.O durante a execução) e repriorizá-las; Trabalhar com o Scrum Master da Contratada para reformular a equipe; Repriorização do Backlog; Solicitar o fechamento de um release com as funcionalidades demonstradas sozinhas ou com incremento de Sprints anteriores; Escolher não avançar mais com o projeto ou não autorizar outra Sprint; Metodologia de Gestão e Desenvolvimento de Sistemas 25/61

156 Solicitar que o progresso do projeto seja acelerado, redefinindo o tamanho do Time; Repassar avaliação dos critérios de aceitação para o subprocesso Avaliar Qualidade. O fluxo segue para o Subprocesso de Avaliar Qualidade, descrito adiante neste documento. Nota: Após os subprocessos Avaliar Qualidade e Homologação (homologação da OS pelo Cliente), se o produto estiver planejado para ser posto em produção (necessário artefato Procedimento de Implantação ), o Gerente de Projetos do Inep (Product Owner) abre uma demanda no Sistema de Demandas do Inep para implantação do produto em produção. Desta forma, o fluxo é direcionando para a atividade Realizar deploy em produção e o fluxo do processo de Execução é finalizado. Em paralelo, é executado o Subprocesso Medição de PFs, descrito adiante neste documento e a atividade Realizar reunião de retrospectiva. A saída do subprocesso Medição de PF são os PFs detalhados da Sprint, que se tornam insumos para o subprocesso de Encerramento da OS, responsáveis pelo encerramento da Ordem de Serviço da Sprint. Realizar reunião de retrospectiva Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar reunião para avaliar os pontos fortes e fracos durante a execução da Sprint, visando melhorias no processo de trabalho. Contratada. Gerente de Projetos do Inep (Product Owner); Backlog da Sprint; Avaliação da Sprint; Ferramentas e Técnicas do Scrum. Avaliação da Sprint. Retrospectivas são ajustes naturais em um ambiente de trabalho ágil. Este é um dos pilares do Scrum, o qual inclui explicitamente ciclos de inspeção e adaptação de métodos e trabalhos em equipe, juntamente com mecanismos para analisar e melhorar o produto. Esta cerimônia ajuda as pessoas a melhorar as práticas, suportar problemas e obstáculos. O Gerente de Projetos do Inep (Product Owner) poderá ser convidado para esta reunião. Após analisar e debater o trabalho realizado na Sprint, a Contratada poderá, caso julgue necessário, atualizar o artefato Avaliação do Sprint com o registro das lições aprendidas e das ações de melhoria para as próximas Sprints, encaminhando-o para o Gerente de Projetos do Inep (Product Owner) e para o Gestor do Contrato. Após esta atividade, o fluxo segue para o subprocesso de Encerramento. NOTA: Este processo representa o fim da Sprint. Realizar a implantação no ambiente de produção Finalidade Responsável Participantes Realizar a implantação, no ambiente de produção, dos produtos gerados pela Sprint. Área de Infraestrutura do Inep. Contratada; Gerente de Projetos do Inep (Product Owner); Analista de Processos do Inep. Metodologia de Gestão e Desenvolvimento de Sistemas 26/61

157 Insumos Código-fonte e testes unitários; Procedimento de implantação; Sistema de Demandas do Inep; Subversion. Produtos/Resultados Sistema disponível no ambiente de produção. A Área de Infraestrutura do Inep realiza a implantação conforme a demanda aberta no Sistema de Demandas do Inep pelo Gerente de Projetos do Inep. Metodologia de Gestão e Desenvolvimento de Sistemas 27/61

158 4 Fase de Encerramento Detalhamento das Atividades da Fase de Encerramento Início do processo O processo começa quando um dos seguintes eventos ocorrer: PFs da fase de iniciação aceitos Este evento é disparado após o aceite da contagem estimativa (de todo o sistema) realizada pela Contratada durante a Fase de Iniciação. O fluxo segue para o processo Encerrar a Ordem da fase de iniciação. PFs do serviço aceitos Este evento é disparado após a implantação do sistema modificado em produção (já homologado pelo Cliente) e quando do aceite da contagem final dos pontos de função do fluxo unitário (nos casos em que a OS não seja de garantia). O fluxo segue para o processo Encerrar a Ordem de Serviço de manutenção (para itens fora da garantia). Serviço em garantia concluído Este evento é disparado após a implantação do sistema modificado em produção (já Metodologia de Gestão e Desenvolvimento de Sistemas 28/61

159 homologado pelo Cliente). Para este tipo de serviço não existe contagem dos pontos de função envolvidos, pois se trata de uma Ordem de Serviço de garantia. O fluxo segue para o processo Encerrar a Ordem de Serviço de garantia. PFs da fase de execução aceitos Este evento é disparado após o aceite da contagem final dos pontos de função da Sprint de execução. O fluxo segue para o processo Encerrar a Ordem de Serviço de Execução. Encerrar a Ordem de Serviço da fase de iniciação Finalidade Responsável Participantes Insumos Produtos/Resultados Dar o aceite na Ordem de Serviço da fase de iniciação. Gestor do Contrato no Inep; Gerente de Projetos do Inep. Contratada. Ordem de Serviço da fase de iniciação com aceite do Cliente; Check-list da OS; Subversion. Ordem de Serviço da fase de iniciação atestada pelo Inep. O Gerente de Projetos do Inep verifica se os seguintes critérios foram atendidos: Toda a documentação prevista na Ordem de Serviço está entregue e aceita; Toda a documentação prevista na Ordem de Serviço está disponível e atualizada no repositório de dados de gerenciamento de Ordens de Serviço; O escopo/detalhamento da demanda está validado e aprovado pelo Cliente (Ordem de Serviço da Fase de Iniciação assinada pelo Cliente); A qualidade da documentação entregue está avaliada e aceita pela área de TI; A contagem estimativa de pontos de função da demanda está validada e aceita pelo Inep; Quando todos os critérios acima estiverem atendidos, o Gestor do Contrato no Inep calcula um percentual de 5% (cinco por cento) dos pontos de função estimados, informa esse valor na Ordem de Serviço, coleta a assinatura do Preposto da Contratada e, em conjunto com o Gerente de Projetos do Inep, faz o ateste da Ordem de Serviço, deixando-a passível de faturamento. Encerrar a Ordem de Serviço de manutenção Finalidade Responsável Participantes Insumos Produtos/Resultados Dar o aceite na Ordem de Serviço de fluxo unitário. Gestor do Contrato no Inep; Gerente de Projetos do Inep. Contratada. Ordem de Serviço com aceite do Cliente; Check-list da OS; Subversion. Ordem de Serviço de manutenção atestada pelo Inep. O Gerente de Projetos do Inep verifica se os seguintes critérios foram atendidos: Toda a documentação prevista na Ordem de Serviço está entregue e aceita; Toda a documentação prevista na Ordem de Serviço está disponível e atualizada no repositório de dados de gerenciamento de Ordens de Serviço; A qualidade do serviço está avaliada e aceita pela área de TI; Metodologia de Gestão e Desenvolvimento de Sistemas 29/61

160 O serviço está homologado pelo Cliente (Ordem de Serviço assinada pelo Cliente); A contagem final de pontos de função do Serviço de Manutenção está validada e aceita pelo Inep. Quando todos os critérios acima estiverem atendidos, o Gestor do Contrato no Inep registra na OS a quantidade de pontos de função aceita, coleta a assinatura do Preposto da Contratada e, em conjunto com o Gerente de Projetos do Inep, faz o ateste da Ordem de Serviço, deixando-a passível de faturamento. Encerrar a Ordem de Serviço de garantia Finalidade Responsável Participantes Insumos Produtos/Resultados Dar o aceite na Ordem de Serviço de garantia. Gestor do Contrato no Inep; Gerente de Projetos do Inep. Contratada. Ordem de Serviço com aceite do Cliente; Check-list da OS; Subversion. Ordem de Serviço de garantia aceita. O Gerente de Projetos do Inep verifica se os seguintes critérios foram atendidos: Toda a documentação prevista na Ordem de Serviço está entregue e aceita; Toda a documentação prevista na Ordem de Serviço está disponível e atualizada no repositório de dados de gerenciamento de Ordens de Serviço; A qualidade do serviço está avaliada e aceita pela área de TI; O serviço está homologado pelo Cliente (Ordem de Serviço assinada pelo Cliente); Quando todos os critérios acima estiverem atendidos, o Gestor do Contrato, em conjunto com o Gerente de Projetos do Inep, faz o ateste da Ordem de Serviço. Para este tipo de Ordem de Serviço não temos faturamento (sem ônus para o Inep). Encerrar a Ordem de Serviço de execução Finalidade Responsável Participantes Insumos Produtos/Resultados Dar o aceite na Ordem de Serviço da Sprint de execução. Gestor do Contrato no Inep; Gerente de Projetos do Inep (Product Owner). Contratada. Ordem de Serviço com aceite do Cliente (assinada pelo Cliente); Check-list da OS; Subversion. Ordem de Serviço da Sprint atestada pelo Inep. O Gerente de Projetos do Inep verifica se os seguintes critérios foram atendidos: Toda a documentação prevista na Ordem de Serviço está entregue e aceita; Toda a documentação prevista na Ordem de Serviço está disponível e atualizada no repositório de dados de gerenciamento de Ordens de Serviço; A qualidade dos produtos do sprint está avaliada e aceita pela área de TI; Os produtos do sprint estão homologados pelo Cliente (se homologáveis); Metodologia de Gestão e Desenvolvimento de Sistemas 30/61

161 A contagem final de pontos de função do sprint está validada e aceita pelo Inep. Quando todos os critérios acima estiverem atendidos, o Gestor do Contrato no Inep registra na OS a quantidade de pontos de função aceita, coleta a assinatura do Preposto da Contratada e, em conjunto com o Gerente de Projetos do Inep, faz o ateste da Ordem de Serviço, deixando-a passível de faturamento. Caso o Backlog não possua mais itens ou a Visão do projeto foi atingida, a entrega final do produto é formalizada pelo Gerente de Projetos do Inep (Product Owner). Metodologia de Gestão e Desenvolvimento de Sistemas 31/61

162 5 Avaliar Qualidade Metodologia de Gestão e Desenvolvimento de Sistemas 32/61

163 Detalhamento das Atividades do Subprocesso Avaliar Qualidade Realizar deploy em homologação de TI Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar a implantação no ambiente de homologação de TI. Área de Infraestrutura do Inep. Contratada; Gerente de Projetos do Inep; Analista de Processos do Inep. Código-fonte; Procedimento de implantação; Demanda aberta no Sistema de Demandas do Inep; Subversion. Sistema disponível no ambiente de homologação de TI. A Área de Infraestrutura do Inep realiza a implantação conforme a demanda aberta no Sistema de Demandas pela Contratada. O fluxo segue para o processo Avaliar a qualidade. Avaliar a qualidade Finalidade Responsável Participantes Avaliar as funcionalidades e artefatos desenvolvidos/atualizados na Sprint ou na execução de manutenção, com foco na garantia da qualidade dos (sub) produtos entregues. Gerente de Projetos do Inep; Contratada; Analista de Processos do Inep; Analistas de Testes e Qualidade de Software do Inep; Administrador de Dados; Arquitetos de software. Metodologia de Gestão e Desenvolvimento de Sistemas 33/61

164 Insumos Ordem de Serviço da fase de Execução com status Execução Finalizada ou Ordem de Serviço da fase de Execução com status Não-conformidade Finalizada ; Código-fonte e testes unitários; Scripts dos testes funcionais; Documentação do sistema (todos os artefatos e demais produtos gerados ou atualizados pelo sprint atual); Guia de Arquitetura; Guia de Desenvolvimento de Sistemas; Guia de Banco de Dados; Procedimento de teste (disponível na Produtos/Resultados Guia de Segurança da Informação para Desenvolvimento de Sistemas. Produto homologado pela área de TI; ou Lista de não-conformidades encontradas. Ordem de Serviço da fase de Execução com status Não Conforme ou Conforme ; Gerente de Projetos do Inep (Product Owner) verifica se o (sub) produto com os artefatos solicitados na OS (projeto ou manutenção) ou apontados na lista de não-conformidades foram entregues. Caso o (sub) produto com todos os artefatos solicitados forem entregues pela contratada, realizar os seguintes procedimentos: Gerente de Projetos do Inep (Product Owner) abre uma demanda no sistema Inep demandas, encaminhando às devidas áreas competentes, com a finalidade de verificação à luz dos padrões definidos pelo Inep e aderência ao negócio (escopo previsto no projeto ou manutenção), os seus respectivos artefatos (via link do SVN). Ex: casos de teste e código para a equipe de testes e qualidade do Inep, código para a equipe de arquitetura e história do usuário ou casos de uso para a equipe de análise de requisito do projeto (caso exista); As áreas deverão fazer a verificação do (sub) produto entregue ou da lista de nãoconformidades corrigida pela Contratada (caso haja) e seguir os procedimentos mínimos descritos abaixo para os projetos ou, quando couber, para a manutenção: o Os Analistas de Teste e Qualidade do Inep realizam testes de aceitação. A equipe de Metodologia de Gestão e Desenvolvimento de Sistemas 34/61

165 o o testes valida uma amostra dos casos de testes entregues e realiza testes pertinentes às funcionalidades do sistema, como teste de regressão e funcional. Como premissa para esta atividade, a Contratada deverá ter seguido o Procedimento de teste disponível na Os Arquitetos de Sistemas do Inep avaliam a qualidade do código-fonte de acordo com o Guia de Arquitetura e o Guia de Desenvolvimento de Sistemas; A equipe de análise de requisitos (Product Owner, Analista de Processos do Inep, ou Analista de Requisitos) verifica os documentos entregues pela Contratada à luz dos padrões definidos pelo Inep e os avalia em relação à aderência ao negócio (visão, backlog do projeto e meta da Sprint; ou demanda de manutenção); Após o tempo acordado para a homologação, o Gerente de Projetos do Inep (Product Owner) receberá o feedback das equipes responsáveis. Durante essa atividade, a Ordem de Serviço da fase de Execução ficará com status Em avaliação ; Caso todos os artefatos solicitados na OS não forem entregues ou não-conformidades sejam encontradas, o Gerente de Projetos do Inep (Product Owner) informa a(s) não-conformidade(s) no CCP e o fluxo é direcionado para a atividade Tratar não-conformidades para as correções necessárias. A OS ficará com o status de Não-conforme. Caso contrário, e se não houver testes de stress, o Gerente de Projetos do Inep (Product Owner) homologa o produto e seus artefatos da fase de Execução e submete a avaliação no CCP. O status da OS é alterado para Conforme e o fluxo do subprocesso é finalizado. Se os testes de stress foram solicitados pelo Gerente de Projetos do Inep (Product Owner) ou a Contratada perceba que há necessidade dos mesmos, esta deverá abrir uma demanda no sistema de demandas do Inep solicitando um deploy no ambiente de homologação do Inep, sempre acordado com Gerente de Projetos do Inep (Product Owner), e o fluxo segue para a atividade Realizar deploy em homologação do Inep. O status da Ordem de Serviço da fase de Execução continua com status Em avaliação. Metodologia de Gestão e Desenvolvimento de Sistemas 35/61

166 Tratar não-conformidades Finalidade Responsável Participantes Insumos Produtos/Resultados Corrigir não-conformidades encontradas na atividade Avaliar a qualidade. Contratada. Gerente de Projetos do Inep (Product Owner). Ordem de Serviço da fase de execução com status Não-conforme ; Lista de não-conformidades encontradas; Documento de Visão; Documento de Arquitetura do Projeto; Modelo de Dados; Especificações de Casos de Uso ou Estórias de Usuário; Protótipo; Subversion; Código-fonte e testes unitários; Documentação do sistema (todos os artefatos e demais produtos gerados ou atualizados pela Sprint atual); Ferramentas e Técnicas do Scrum; Técnicas do XP; Guia de Arquitetura; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas; Guia de Desenvolvimento de Sistemas. Lista de não-conformidades encontrada atualizada; Artefatos atualizados; Ordem de Serviço da fase de Execução com status Não-conformidade Finalizada. A Contratada recebe a lista de não-conformidades via CCP e deverá tratá-las em observância ao prazo estipulado no contrato de desenvolvimento e manutenção de sistemas vigente até 48 horas no caso de avaliação da qualidade realizada antes do subprocesso de homologação; e até 24 horas para o atendimento decorrente da avaliação da qualidade chamada pelo subprocesso de homologação. Durante esta atividade, o status da OS ficará como Tratando não-conformidade. A qualquer momento, se houver necessidade de serviços de infraestrutura, banco de dados (alteração Metodologia de Gestão e Desenvolvimento de Sistemas 36/61

167 no modelo de dados, por exemplo) ou de suporte, a Contratada registra uma demanda no Sistema de Demandas, sempre dando ciência ao Product Owner. Após a conclusão da atividade Tratar não-conformidades, a OS será liberada com status Nãoconformidade Finalizada e o fluxo retornará para a atividade Avaliar a qualidade. Realizar deploy em homologação do Inep Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar a implantação no ambiente de homologação do Inep. Área de Infraestrutura do Inep. Contratada; Gerente de Projetos do Inep; Analista de Processos do Inep. Código-fonte; Procedimento de implantação; Demanda aberta no Sistema de Demandas. Sistema disponível no ambiente de homologação do Inep. A Área de Infraestrutura do Inep realiza a implantação conforme a demanda aberta no Sistema de Demandas do Inep. O fluxo segue para a atividade Realizar testes de stress. Realizar testes de stress Finalidade Responsável Participantes Submeter o software a situações extremas e anormais, avaliando o comportamento do sistema em situações onde há poucos recursos ou há concorrência por recursos. Contratada; Analistas de Testes e Qualidade de Software do Inep. Gerente de Projetos do Inep; Analista de Processos do Inep; Metodologia de Gestão e Desenvolvimento de Sistemas 37/61

168 Insumos Administrador de Dados; Área de Infraestrutura do Inep; Arquitetos de software. Sistema no ambiente adequado (homologação do Inep); Ordem de Serviço da fase de Execução com status Em avaliação ou Ordem de Serviço da fase de Execução com status Não-conformidade Finalizada (caso a OS tenha passado pela atividade Tratar não-conformidades ); Especificações de Casos de Uso ou Estórias de Usuário; Procedimento de teste disponível na Produtos/Resultados Massa de dados válida. Produto homologado pela área de TI ou produto a ser analisado para tratar falhas; Ordem de Serviço da fase de Execução com status Conforme ou Em avaliação. Os testes de stress são fundamentais em aplicações em que a eficiência seja uma característica importante. A Contratada deve utilizar o sistema com recursos em quantidade e freqüência anormais, avaliando seu comportamento, como a perda de desempenho do sistema e a sua suscetibilidade de falhas durante os testes. É possível variar parâmetros como carga de CPU, memória disponível, espaço em disco disponível, carga de rede, capacidade máxima especificada de clientes ou processos executando, alta concorrência por recursos, entre outros. Esta atividade deverá ser compartilhada com a equipe de Analistas de Testes e Qualidade, equipe de Infraestrutura, Banco de Dados e Redes do Inep, as quais analisarão o comportamento do sistema e verificarão as possíveis causas de falhas ou baixo desempenho. Caso sejam detectados problemas durante os testes, estes deverão ter suas causas analisadas e tratadas. Assim, o fluxo segue para a atividade Analisar e tratar falhas. Caso a aplicação atenda aos requisitos dos testes realizados, a equipe de Analistas de Testes e Qualidade de Software do Inep avalia a atividade como Conforme e o Gerente de Projetos do Inep (Product Owner) submete a avaliação no CCP. O status da OS é alterado para Conforme e o fluxo do subprocesso é finalizado. Metodologia de Gestão e Desenvolvimento de Sistemas 38/61

169 Analisar e tratar falhas Finalidade Responsável Participantes Insumos Analisar as possíveis causas de falhas ou baixo desempenho nos testes de stress (decorrentes do ambiente do Inep) e tratá-los. Analistas de Testes e Qualidade de Software, Analistas de Dados, Área de Infraestrutura e Analista de Redes do Inep. Gerente de Projetos do Inep; Contratada; Arquitetos de software. Sistema no ambiente adequado (homologação do Inep); Especificações de Casos de Uso ou Estórias de Usuário; Procedimento de teste disponível na Evidência de falha(s) nos testes de stress; Produtos/Resultados Massa de dados válida. Problemas diagnosticados e tratados ou Ordem de Serviço da fase de Execução com status Não-conforme. Caso sejam detectados problemas durante os testes, estes deverão ter suas causas analisadas e tratadas por todos os envolvidos na atividade, de acordo com a natureza do problema. A participação da Contratada nesta atividade é focada na disponibilidade para possíveis esclarecimentos sobre os trabalhos já realizados. Se algum desses problemas for relacionado ao código desenvolvido, a equipe de Analistas de Testes e Qualidade de Software do Inep avaliará a atividade como Não-conforme e o Gerente de Projetos do Inep (Product Owner) submete a avaliação no CCP. O fluxo segue para Tratar não-conformidades stress. Caso contrário, a atividade será executada até que o produto esteja pronto para um novo teste de stress. Desta forma, o fluxo retorna para a atividade Realizar testes de stress. Metodologia de Gestão e Desenvolvimento de Sistemas 39/61

170 Tratar não-conformidades stress Finalidade Responsável Participantes Insumos Produtos/Resultados Corrigir não-conformidades encontradas na atividade Analisar e tratar falhas provenientes de problemas no código. Contratada. Gerente de Projetos do Inep (Product Owner); Analistas de Testes e Qualidade de Software; Analistas de Dados; Área de Infraestrutura; Analista de Redes do Inep. Ordem de Serviço da fase de execução com status Não-conforme ; Lista de não-conformidades encontradas; Documento de Arquitetura do Projeto; Modelo de Dados; Especificações de Casos de Uso ou Estórias de Usuário; Protótipo; Subversion; Código-fonte e testes unitários; Documentação do sistema (todos os artefatos e demais produtos gerados ou atualizados pela Sprint atual); Ferramentas e Técnicas do Scrum; Técnicas do XP; Guia de Arquitetura; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas; Guia de Desenvolvimento de Sistemas. Lista de não-conformidades encontrada atualizada; Artefatos atualizados; Ordem de Serviço da fase de Execução com status Não-conformidade Finalizada. A Contratada recebe a lista de não-conformidades via CCP (desempenho de consultas, por exemplo) e Metodologia de Gestão e Desenvolvimento de Sistemas 40/61

171 deverá tratá-las em observância ao prazo estipulado no contrato de desenvolvimento e manutenção de sistemas vigente até 48 horas no caso de avaliação da qualidade realizada antes do subprocesso de homologação; e até 24 horas para o atendimento decorrente da avaliação da qualidade chamada pelo subprocesso de homologação. Durante esta atividade, o status da OS ficará como Tratando nãoconformidade. A qualquer momento, se houver necessidade de serviços de infraestrutura ou de suporte, a Contratada registra uma demanda no Sistema de Demandas, dando ciência ao Product Owner. Após a conclusão da atividade Tratar não-conformidades, a OS será liberada com status Nãoconformidade Finalizada e o fluxo retornará para a atividade Realizar testes de stress. Metodologia de Gestão e Desenvolvimento de Sistemas 41/61

172 5.1 Homologação Metodologia de Gestão e Desenvolvimento de Sistemas 42/61

173 Detalhamento das Atividades do Subprocesso Homologação Início do processo O Subprocesso é chamado quando o subproduto do projeto encontra-se homologado sob o ponto de vista da TI (após passar pelo subprocesso Avaliar Qualidade ) e a reunião de revisão da Sprint foi realizada pela Contratada ou quando o produto da demanda de manutenção encontra-se homologado sob o ponto de vista da TI (após passar pelo subprocesso Avaliar Qualidade ). O Gerente de Projetos do Inep (Product Owner) abre um registro de demanda no sistema de demandas do Inep solicitando implantação do produto no ambiente de homologação do Inep. O fluxo segue conforme a atividade Realizar deploy em homologação Inep. Realizar deploy em homologação Inep Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar a implantação no ambiente de homologação do Inep. Área de Infraestrutura do Inep. Contratada; Gerente de Projetos do Inep; Analista de Processos do Inep. Código-fonte; Procedimento de implantação; Demanda aberta no Sistema de Demandas do Inep. Sistema disponível no ambiente de homologação do Inep. A Área de Infraestrutura do Inep realiza a implantação conforme a demanda aberta no Sistema de Demandas do Inep. O fluxo segue para a atividade Homologar sprint. Homologar Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar a homologação das funcionalidades implementadas e/ou modificadas. Cliente. Gerente de Projetos do Inep (Product Owner); Contratada; Analista de Processos do Inep. Sistema disponível no ambiente de homologação do Inep; Ordem de Serviço da fase de Execução com status Em homologação ; Documentação do sistema. Ordem de Serviço da fase de Execução com status Homologada ou Ordem de Serviço da fase de Execução com status Não homologada ; Lista de não-conformidades. O Gerente de Projetos do Inep (Product Owner) formaliza junto ao cliente a disponibilidade da demanda para homologação. Caso a homologação seja aceita, o Cliente dará ciência (via , reunião, memorando) ao Gerente de Projetos do Inep (Product Owner). Havendo mudanças de requisitos, o Cliente e o Gerente de Projetos do Inep (Product Owner) determinarão, mediante necessidade, se a mudança entrará para o Backlog para ser tratada nas próximas Sprints, ou será tratada como manutenção - o fluxo seguirá para o subprocesso Executar Manutenção. Nesses casos, a Ordem de Serviço da fase de Execução deverá Metodologia de Gestão e Desenvolvimento de Sistemas 43/61

174 ficar com status Homologada. Caso sejam encontradas não-conformidades com os requisitos originais, o Gerente de Projetos do Inep registra e encaminha a lista de não-conformidades à Contratada, para providências. O fluxo segue para a atividade "Tratar não-conformidades de homologação". Após dois dias úteis sem retorno do cliente sobre a homologação, a Ordem de Serviço da fase de Execução será homologada tacitamente. Tratar não-conformidades de homologação Finalidade Responsável Participantes Insumos Produtos/Resultados Resolver as não-conformidades encontradas durante a homologação das funcionalidades implementadas e/ou modificadas. Contratada. Gerente de Projetos do Inep (Product Owner). Ordem de Serviço da fase de execução com status Não homologada ; Lista de não-conformidades; Documento de Visão; Documento de Arquitetura do Projeto; Modelo de Dados; Especificações de Casos de Uso ou Estórias de Usuário; Protótipo; Subversion; Código-fonte e testes unitários; Documentação do sistema (todos os artefatos e demais produtos gerados ou atualizados pela Sprint atual); Ferramentas e Técnicas do Scrum; Técnicas do XP; Guia de Arquitetura; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas; Guia de Desenvolvimento de Sistemas. Procedimento de Implantação atualizado; Sistema modificado, testado e implantado novamente no ambiente de homologação do Inep. Lista de não-conformidades encontrada atualizada; Artefatos atualizados; Ordem de Serviço da fase de Execução com status Não-conformidade Finalizada. A Contratada recebe a lista de não-conformidades via CCP e deverá tratá-las em observância ao prazo estipulado no contrato de desenvolvimento e manutenção de sistemas vigente até 24 horas. A qualquer momento, se houver necessidade de serviços de infraestrutura ou de suporte, a Contratada registra uma demanda no Sistema de Demandas do Inep, dando ciência ao Gerente de Projetos do Inep (Product Owner). Durante esta atividade, o status da OS ficará como Tratando nãoconformidades. Ao final da atividade, o status da OS ficará como Não-conformidade Finalizada. O fluxo segue para o subprocesso Avaliar Qualidade. Metodologia de Gestão e Desenvolvimento de Sistemas 44/61

175 5.2 Subprocesso Medição de PF Metodologia de Gestão e Desenvolvimento de Sistemas 45/61

176 Detalhamento das Atividades do Subprocesso de Medição de PF Início do processo O Subprocesso começa quando um dos seguintes eventos ocorrer: Necessidade de validação de contagem Este evento é disparado quando um profissional da empresa Contratada tem em seu poder uma contagem estimativa ou detalhada, relativa a uma Ordem de Serviço homologada pelo cliente. Este evento também pode ocorrer quando um Gerente de Projetos/Analista de Processos do Inep tem em seu poder uma contagem estimativa ou detalhada, relativa a uma Ordem de Serviço homologada, e que necessita de validação. Necessidade de realização de contagem Este evento é disparado quando um Gerente de Projetos/Analista de Processos do Inep necessita da realização de uma contagem estimativa para subsidiar a abertura de uma Ordem de Serviço. O fluxo segue conforme a atividade Solicitar atuação do Núcleo de Métricas. Solicitar atuação do Núcleo de Métricas Finalidade Responsável Participantes Insumos Produtos/Resultados Encaminhar solicitação ao Núcleo de Métricas. Interessado (Gerente de Projetos/Analista de Processos do Inep ou profissional da Contratada). Não há. Inep Demandas. Solicitação de atuação do Núcleo de Métricas com status Em Triagem. O interessado acessa o Inep Demandas pelo endereço Após informar suas credenciais de acesso e ser identificado pelo Inep Demandas, o interessado aciona o menu Principal > Cadastrar Demandas (ou utiliza o atalho disponível na aba Cadastrar Demandas). No formulário Cadastro da Demanda que se abrirá, o interessado fornece as seguintes informações: Grupo da demanda: DTDIE Sistemas de Informação. Destino da demanda: Núcleo de Métricas. Tipo da demanda: deve ser escolhido o tipo que melhor se adapte à necessidade. Assunto: Informar o nome/sigla do sistema, o tipo da demanda e o nome da iteração/número da Ordem de Serviço no CCP. Exemplos: 1. CCP Contagem Estimada Cadastro de Contagem Estimada. 2. Inep Demandas Validação de Contagem Detalhada OS 8. Necessidade: neste campo deve ser informado o endereço do projeto no sistema de controle de versões do Inep, um nome de usuário e senha do sistema em ambiente em que possa ser executado pelo Núcleo de Métricas (com os perfis necessários), e quaisquer outras informações que o interessado julgue relevantes para o atendimento de sua demanda. Após fornecer todas as informações, o interessado aciona o botão Salvar. A demanda será então encaminhada eletronicamente ao Núcleo de Métricas, com o status Em Triagem (na triagem, o status da solicitação é modificado para Em Análise ). O fluxo segue conforme a atividade Avaliar as Metodologia de Gestão e Desenvolvimento de Sistemas 46/61

177 condições de atendimento da solicitação. Avaliar as condições de atendimento da solicitação Finalidade Responsável Participantes Insumos Produtos/Resultados Avaliar as condições necessárias ao atendimento à solicitação encaminhada ao Núcleo de Métricas. Analista de Métricas. Não há. Solicitação de atuação do Núcleo de Métricas com status Em Análise ; Documentação disponível no sistema de controle de versões do Inep; Registro de iteração/ordem de Serviço no CCP. Solicitação aceita ou devolvida com pendências. O Analista de Métricas submete a solicitação aos seguintes critérios: A Ordem de Serviço (se houver) encontra-se homologada pelo cliente; A solicitação de atuação do Núcleo de Métricas contém todas as informações necessárias à execução do trabalho solicitado; A documentação necessária encontra-se disponível no diretório apropriado do sistema de controle de versões do Inep e possui a qualidade necessária para possibilitar a realização do trabalho solicitado; A aplicação encontra-se disponível no ambiente de homologação e os privilégios de acesso são suficientes (se for o caso). Quando todos os critérios forem atendidos, o fluxo segue conforme a atividade Atender à solicitação. Quando forem encontrados problemas que prejudiquem o atendimento à solicitação, o fluxo segue conforme a atividade Devolver com pendência. NOTA: Se entender que não é necessário devolver a solicitação com as pendências, o Analista de Métricas pode solicitar ao interessado esclarecimentos e/ou fornecimento de informações ou documentos adicionais. Devolver com pendência Finalidade Responsável Participantes Insumos Produtos/Resultados Devolver ao interessado a Solicitação de atuação do Núcleo de Métricas com pendência. Analista de Métricas. Não há. Solicitação de atuação do Núcleo de Métricas com status Em Análise ; Lista de pendências. Lista de pendências registrada no Inep Demandas; Solicitação de atuação do Núcleo de Métricas com status Pendente Solicitante. Se forem encontrados problemas que prejudiquem o atendimento à demanda, o Analista de Métricas muda o status da solicitação para Pendente Solicitante, registra as pendências encontradas e encaminha a solicitação eletronicamente ao solicitante. O fluxo segue conforme a atividade Resolver a pendência. Metodologia de Gestão e Desenvolvimento de Sistemas 47/61

178 Resolver a pendência Finalidade Responsável Participantes Resolver as pendências listadas e reencaminhar a Solicitação de atuação do Núcleo de Métricas para atendimento. Interessado (Gerente de Projetos/Analista de Processos do Inep ou profissional da Contratada). Não há. Insumos Solicitação de atuação do Núcleo de Métricas com status Pendente Solicitante ; Produtos/Resultados Lista de pendências registradas no Inep Demandas. Solicitação de atuação do Núcleo de Métricas com status Em Análise. O interessado resolve as pendências listadas pelo Núcleo de Métricas e reencaminha a Solicitação de atuação do Núcleo de Métricas com status Em Análise. O fluxo retorna à atividade Avaliar as condições de atendimento da solicitação. Atender à solicitação Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar a atividade solicitada. Analista de Métricas. Interessado (Gerente de Projetos/Analista de Processos do Inep ou profissionais da Contratada). Solicitação de atuação do Núcleo de Métricas com status Em Análise ; Documentação disponível no sistema de controle de versões do Inep; Registro de iteração/ordem de Serviço no CCP; Aplicação disponível no ambiente de homologação (se for o caso). Solicitação atendida. O Analista de Métricas muda o status da solicitação para em atendimento. Para solicitação de contagem O Analista de Métricas realiza as seguintes tarefas: Obtém, no sistema de controle de versões do Inep, a última versão da documentação do sistema; Realiza a contagem solicitada, gravando-a no diretório Métricas do projeto (se esse diretório não existir, ele será criado pelo Analista de Métricas); Atualiza a documentação no sistema de controle de versões do Inep com a contagem solicitada; Altera o status da solicitação de atuação do núcleo de métricas para Finalizada, informando a localização da planilha estimativa. O fluxo segue conforme a atividade Atualizar a base histórica de medições. Para solicitação de validação de contagem O Analista de Métricas realiza as seguintes tarefas: Obtém, no sistema de controle de versões do Inep, a última versão da documentação do sistema e da contagem de pontos de função; Grava uma cópia da contagem de pontos de função original, acrescentando ao nome do arquivo o identificador _Validada ; Realiza a validação da contagem, registrando as divergências encontradas (se houver) na Metodologia de Gestão e Desenvolvimento de Sistemas 48/61

179 contagem validada; Atualiza a documentação no sistema de controle de versões do Inep com a contagem validada. Se, ao término da validação, não houver divergências na contagem, o Analista de Métricas registra o aceite na contagem validada. Se, ao término da validação, houver divergências na contagem, o Analista de Métricas muda o status da solicitação para Pendente Solicitante e registra a necessidade de uma reunião com o profissional responsável pela contagem para solucionar as divergências. Essa reunião dará como resultado um acordo para a versão final da contagem. O Analista de Métricas registra esse acordo na contagem validada e informa, no mesmo documento, o aceite da versão final da contagem. O Analista de Métricas muda o status da solicitação para Finalizada, informando a localização da planilha validada. O fluxo segue conforme a atividade Atualizar a base histórica de medições. Se, durante a realização do trabalho, forem encontradas pendências, o Analista de Métricas muda o status da solicitação para Pendente Solicitante, registra as pendências encontradas e encaminha a solicitação eletronicamente ao solicitante. Este, por sua vez, resolve as pendências listadas pelo Analista de Métricas e reencaminha a Solicitação de atuação do Núcleo de Métricas com status Em Análise. Esse fluxo será executado sempre que forem identificadas pendências que impeçam a finalização do trabalho. Tão logo a solicitação esteja com o status Finalizada, o solicitante é notificado automaticamente por e- mail enviado pelo Inep Demandas. NOTA: A qualquer tempo o Analista de Métricas pode solicitar esclarecimentos ou fornecimento de informações/ documentos adicionais aos envolvidos/interessados. Atualizar a base histórica de medições Finalidade Responsável Participantes Insumos Produtos/Resultados Manter atualizada a base histórica de medições de pontos de função. Analista de Métricas. Não há. Contagem estimativa de pontos de função elaborada; ou Contagem detalhada de pontos de função validada. Base histórica de medições atualizada. O Analista de Métricas registra a contagem de pontos de função no controle geral de medições e atualiza o documento no sistema de controle de versões do Inep. Na sequência, notifica por o gestor e o co-gestor do contrato, informando o número da Ordem de Serviço relativa à contagem aceita. Se a contagem de pontos de função for estimativa, o fluxo do processo de medição de pontos de função é finalizado. Se for uma contagem detalhada, o fluxo segue conforme a atividade Atualizar a linha de base de pontos de função. Atualizar a linha de base de Pontos de Função Finalidade Responsável Participantes Insumos Produtos/Resultados Manter atualizada a linha de base de pontos de função do sistema. Analista de Métricas. Não há. Contagem detalhada de pontos de função aceita. Linha de base de pontos de função do sistema atualizada. O Analista de Métricas atualiza a linha de base de pontos de função existente com os itens da contagem detalhada de pontos de função. Metodologia de Gestão e Desenvolvimento de Sistemas 49/61

180 Se a linha de base não existir, o Analista de Métricas a cria com os itens da contagem detalhada de pontos de função aceita. O fluxo do processo de medição de pontos de função é finalizado. Metodologia de Gestão e Desenvolvimento de Sistemas 50/61

181 5.3 Executar Manutenção Detalhamento das Atividades de Executar Manutenção Repassar demanda Finalidade Responsável Participantes Insumos Produtos/Resultados Analisar a demanda com a finalidade de evidenciar necessidade de manutenção no software. Gerente de Projetos do Inep (Product Owner). Cliente; Gerente de Projetos do Inep (Product Owner); Analista de Processos do Inep; Arquiteto de Sistemas do Inep; Área de Suporte do Inep; Área de Infraestrutura do Inep. Documentação do sistema; Documento de Requisitos para Manutenção; Evidências do(s) erro/problema(s) no software. Documento de Requisitos para Manutenção (refinado). O Gerente de Projetos do Inep (Product Owner) e o Analista de Processos do Inep deverão obter Metodologia de Gestão e Desenvolvimento de Sistemas 51/61

182 evidências do(s) erro/problema(s) no software. Tais evidências poderão ser, por exemplo, registros de banco de dados, consultas ao log do sistema, impressões de tela, etc. O Gerente de Projetos do Inep (Product Owner) deverá convocar reunião com a Contratada para alinhar o entendimento do problema e as evidências elaboradas, que servirão de insumo para a execução da manutenção. Caso seja necessário, os demais participantes (Arquiteto de Sistemas do Inep, Área de Suporte do Inep e a Área de Infraestrutura do Inep) poderão ser convidados para fornecer parecer técnico ou específico do domínio em questão. Nessa atividade, serão definidos e acordados: Requisitos envolvidos na demanda; Documentação que será atualizada; Critérios de aceitação; Tempo de execução da demanda. A tabela abaixo poderá ser utilizada como referência para o acordo entre as partes na definição do prazo de atendimento. Prioridade Impacto Tempo de resolução Alta Média Baixa Urgência Alto Crítico Alto Médio <2 horas <6 horas <12 horas Médio Alto Médio Baixo <6 horas <12 horas <48 horas Baixo Médio Baixo Planejamento <12 horas <48 horas Planejado Impacto: Está relacionado ao efeito nos processos de negócio ou finalísticos do Inep, quanto os serviços serão afetados com aquela falha, necessidade de evolução ou necessidade de adaptação e qual será o transtorno pela não realização da respectiva manutenção. Urgência: Está relacionada a quanto uma falha, necessidade de evolução ou necessidade de adaptação pode afetar um processo de negócio ou finalístico do Inep, e indica a velocidade com que a Contratada deverá realizar a manutenção. Após esta atividade, o fluxo segue para a atividade Elaborar OS de garantia, caso o código tenha sido desenvolvido pela Contratada, ou caso contrário, se a demanda não for crítica, o fluxo segue para a atividade Estimar PFs. Se a demanda for crítica, o fluxo segue para a atividade Elaborar OS de serviço de manutenção. Metodologia de Gestão e Desenvolvimento de Sistemas 52/61

183 Elaborar OS de garantia Finalidade Responsável Participantes Insumos Produtos/Resultados Gerar OS de garantia. Gerente de Projetos do Inep (Product Owner). Contratada; Gestor do Contrato no Inep. Documento de Requisitos para Manutenção com evidências da necessidade de correção de código implementado pela Contratada. Ordem de Serviço da fase de execução com status Em andamento. O Gerente de Projetos do Inep (Product Owner) cadastra a demanda de manutenção no sistema de Controle de Contratos e Projetos do Inep (CCP), juntamente com a evidência dos pré-requisitos para manutenção de garantia. A OS fica com o status de Em Elaboração. Se a demanda for considerada de prioridade crítica, o Gerente de Projetos do Inep (Product Owner) deverá justificar tal característica e a emissão da OS será automática. Para as demais prioridades da OS (definidas na atividade Repassar demanda, o Gestor do Contrato emite a OS oficialmente, autorizando a Contratada a realizar a execução da manutenção. Desta forma, OS fica com status de Emitida. Após emissão da OS, exceto para as de prioridade classificada como crítica, que serão automaticamente aceitas, a Contratada poderá aceitar ou rejeitar a OS mediante justificativa plausível e aderente ao contrato. Ao final da atividade, o status da OS é alterado para Em andamento e o fluxo segue para a atividade Executar a manutenção. Estimar os PFs da demanda de manutenção Finalidade Responsável Participantes Insumos Produtos/Resultados Estimar o tamanho da demanda de manutenção em sistema existente. Analista de Métricas. Interessado (Gerente de Projetos/Analista de Processos do Inep ou especialista em pontos de função da Contratada). Guia de Contagem de Pontos de Função do Inep; Documento de Requisitos para Manutenção; Modelo de Dados; Especificação de caso de uso ou histórias de usuário; Acesso ao sistema em produção e Protótipo. Planilha de contagem estimativa de pontos de função da demanda. O responsável estima os pontos de função da demanda conforme previsto no Guia de Contagem de Pontos de Função do Inep, documentando-a no modelo apropriado, disponível nesta MGDS. Ao final da atividade, o fluxo segue para a atividade Elaborar OS de serviço de manutenção. Elaborar OS de serviço de manutenção Finalidade Gerar OS de serviço de manutenção. Metodologia de Gestão e Desenvolvimento de Sistemas 53/61

184 Responsável Participantes Insumos Produtos/Resultados Gerente de Projetos do Inep (Product Owner). Contratada; Gestor do Contrato no Inep. Documento de Requisitos para Manutenção com evidências da necessidade de correção de código. Ordem de Serviço da fase de execução com status Em andamento. O Gerente de Projetos do Inep (Product Owner) cadastra a demanda de manutenção no sistema de Controle de Contratos e Projetos do Inep (CCP), juntamente com a evidência dos pré-requisitos para manutenção de garantia. A OS fica com o status de Em Elaboração. Se a demanda for considerada de prioridade crítica, o Gerente de Projetos do Inep (Product Owner) deverá justificar tal característica e a emissão da OS será automática. Para as demais prioridades da OS (definidas na atividade Repassar demanda, o Gestor do Contrato emite a OS oficialmente, autorizando a Contratada a realizar a execução da manutenção. Desta forma, OS fica com status de Emitida. Após emissão da OS, exceto para as de prioridade classificada como crítica, que serão automaticamente aceitas, a Contratada poderá aceitar ou rejeitar a OS mediante justificativa plausível e aderente ao contrato. Ao final da atividade, o status da OS é alterado para Em andamento e o fluxo segue para a atividade Executar a manutenção. Executar a manutenção Finalidade Responsável Participantes Insumos Produtos/Resultados Realizar manutenção do software mediante demanda do Inep. Contratada. Gerente de Projetos do Inep (Product Owner); Gestor do Contrato no Inep. Documento de Requisitos para Manutenção; Documentação do sistema. Ordem de Serviço da fase de execução com status Finalizada ; Documentação Técnica da Manutenção; Documentação do projeto e do sistema atualizadas. A Contratada deverá usar o Kanban como ferramenta para executar essa atividade, dando assim, continuidade aos valores ágeis e à transparência dos processos e do fluxo de trabalho preconizados nessa Metodologia. Ademais, o Kanban expõe gargalos, filas, variabilidade e desperdício na quantidade de trabalho de valor entregue. Deverá ser usado um mecanismo de controle visual (quadro) para acompanhar o trabalho à medida que ele flui através das várias etapas do fluxo de valor. Os seguintes tópicos descrevem a essência do sistema Kanban, e assim, deverão ser realizados impreterivelmente pela Contratada: Visualizar o fluxo de trabalho - Dividir a demanda em partes/tarefas, escrever cada item em um cartão e colocar na parede. Usar colunas nomeadas para ilustrar cada item no fluxo de trabalho. Estabelecer o Limite de WIP (work in progress) - atribuir limites explícitos para a quantidade de itens que podem estar em andamento em cada estado do workflow. Fornecendo assim, previsibilidade de tempo em ciclos e entregas mais confiáveis. Metodologia de Gestão e Desenvolvimento de Sistemas 54/61

185 Medir o lead time (tempo médio para concluir um item, às vezes chamado de "ciclo") e aperfeiçoar o processo para fazer com que o lead time seja o menor e mais previsível possível. É atualizado a cada vez que um item atinge o Done ou seja, o concluído. O quadro Kanban deverá esboçar um bom fluxo de trabalho e possibilitar análises para minimizar o lead time. Com esse intuito, poderá haver variações nas suas colunas, variações nos limites do WIP e nas suas regras. Gráficos Burndowns poderão ser usados e compartilhados com o Gerente de Projetos do Inep (Product Owner). Reuniões diárias, advindas das boas práticas do Scrum e conseqüentemente da atividade Executar a Sprint da MGDS, deverão ser realizadas na equipe de manutenção da Contratada com foco no quadro e concentradas nos gargalos e outros problemas visíveis. O Gerente de Projetos do Inep (Product Owner) poderá ser convidado, caso seja necessário. Deverá ocorrer semanalmente uma reunião para inspeção e adaptação do processo de manutenção visando a promoção de melhoria contínua, onde os envolvidos deverão colocar como pauta: Atualizar quadro e gráficos; O que aconteceu na semana, o porquê do acontecimento e o que pode ser feito para melhorar; Reajustar, caso necessário, o limite de atividades em andamento (WIP); Lançar estimativas de novas demandas (se houver necessidade). Abaixo segue exemplo de quadro Kanban com estrutura mínima mediante fluxo de trabalho da MGDS: Fluxo Backlog Selecionado [WIP] Desenvolver [WIP] Avaliação Qualidade Homologação Produção Iniciado Teste Pronto Projeto A Projeto B Projeto C Onde: Os projetos são divididos por raias; WIP = {1, 2, 3, 4...}; Os cartões terão as tarefas, que são agrupadas por histórias ou demandas (OS); As prioridades poderão ser representadas por cores pré-estabelecidas ou descrições nos cartões: Metodologia de Gestão e Desenvolvimento de Sistemas 55/61

186 o Crítica: o Alta: o Média: o Baixa: o Planejado: O WIP da coluna com subdivisões (tipo a Desenvolver no exemplo) é compartilhado; O fluxo segue para o subprocesso Avaliar a qualidade, descrito no tópico cinco (5) desta metodologia. Depois de avaliado, segue para o subprocesso de homologação da demanda, onde a demanda será homologada pelo cliente. Após o subprocesso de homologação, o Gerente de Projetos do Inep (Product Owner) registra o pedido do deploy em produção no Inep demandas, e caso a OS não seja de garantia, o fluxo segue para o subprocesso Medição de PF. Ao final, o fluxo segue para o subprocesso Encerramento. Metodologia de Gestão e Desenvolvimento de Sistemas 56/61

187 6 Conjunto de Artefatos O Conjunto de Artefatos listado abaixo define a documentação necessária e os produtos que deverão ser gerados durante o desenvolvimento de novos sistemas e durante os processos de manutenção de sistemas (a Ordem de Serviço discriminará os artefatos exigidos de acordo com a necessidade). Este conjunto de artefatos é utilizado tanto em insumos quanto em produtos/resultados gerados durante a utilização dos processos da MGDS. A responsabilidade pela elaboração de cada artefato é descrita nos processos da MGDS citados nos itens acima. Em alguns casos, a elaboração e/ou atualização do artefato pode ficar a cargo do Inep e da contratada. Alguns artefatos deverão ser de uso obrigatório da contratada no intuito de que os sistemas desenvolvidos / manutenidos contenham uma documentação mínima necessária. Já os artefatos considerados não obrigatórios poderão ser requeridos eventualmente, ficando a cargo do Gerente de Projetos do Inep definir sua utilização ou não. A Contratada, com a finalidade de contribuir e facilitar o ciclo de vida do desenvolvimento/manutenção do sistema, poderá acordar com o Inep outros artefatos complementares, os quais não serão considerados de uso obrigatório. Segue abaixo a lista dos artefatos, sendo os artefatos sublinhados de uso obrigatório pela contratada: Avaliação da Sprint; Backlog (Backlog e Backlog do Sprint fazem parte do artefato Backlog); Casos de Teste; Check-list da Ordem de Serviço; Controle Integrado de Mudanças; Código-fonte documentado e testes unitários; Diagrama de Classes (definido pela UML); Documento de Requisitos para Manutenção; Documentação Técnica da Manutenção; Documento de Arquitetura do Projeto; Documento de Visão; Especificação de Caso de Uso ou Estórias de Usuário; Lista de Mudanças; Lista Não-conformidades (Visão Cliente); Lista Não-conformidades (Visão TI); Memória de Reunião; Modelo Sintético de Casos de Uso; Modelo de Dados (MER) e Scripts; Ordem de Serviço; Planilha de Pontos de Função (Desenvolvimento e Manutenção de Sistemas); Procedimento de Implantação; Protótipos; Relatório de Cobertura de Testes; Relatório de Status; Solicitação de Mudança; Scripts dos testes funcionais; Metodologia de Gestão e Desenvolvimento de Sistemas 57/61

188 Os modelos dos artefatos encontram-se no SVN, no endereço: Não foram definidos modelos para os artefatos abaixo: Modelo de Dados (MER) e Scripts; Código-fonte documentado e testes unitários; Scripts dos testes funcionais; Protótipos; Diagrama de Classes. 7 Material de Apoio O material de apoio é composto por ferramentas e técnicas que auxiliarão no desenvolvimento de sistemas e nos processos de manutenção de sistemas e servirão como insumos para os processos da MGDS. A lista abaixo não pretende esgotar todas as ferramentas e técnicas disponíveis no mercado e em nossa organização, ou seja, não se trata de uma lista exaustiva. Outras ferramentas e técnicas poderão ser utilizadas de acordo com a necessidade. Guias o o o o o Guia de Arquitetura PHP e Java; Guia de Desenvolvimento de Sistemas; Guia de Banco de Dados; Guia de Segurança da Informação para Desenvolvimento de Sistemas; Guia de Contagem de Pontos de Função do INEP. Os guias encontram-se no SVN, no endereço: Documentos relacionados à metodologia Ferramenta de Prototipação /WireframeSketcherStudio/ Manual de Práticas de Contagem de Pontos de Função (CPM); Procedimentos de Testes: Sistema de Demandas: Inep Demandas, acessado através do link: Sistema de Controle de Contratos e Projetos Metodologia de Gestão e Desenvolvimento de Sistemas 58/61

189 Subversion: no INEP os três principais repositórios são: o Documentos:http://subversion.inep.gov.br/svn/documentos/ o Fontes: o Banco: Ferramentas e Técnicas do Scrum; Técnicas do XP. Metodologia de Gestão e Desenvolvimento de Sistemas 59/61

190 8 Padrão de Nomenclatura e Armazenamento dos Artefatos A tabela abaixo trata da nomenclatura e armazenamento dos artefatos citados no item 6 que possuem modelos definidos: N*, Número_OS e Número_Sprint representam números seqüenciais. Nome do Artefato Nome do Arquivo Armazenamento Documento de Visão [Nome do Sistema]_DV [Diretório do Sistema no SVN]\Analise Documento de Arquitetura do Projeto [Nome do Sistema]_DAP [Diretório do Sistema no SVN]\Analise Especificação de Caso de Uso [Nome do Sistema]_ECU_Nome_Caso_de_Uso [Diretório do Sistema no SVN]\Analise Historia de Usuário [Nome do Sistema]_EU_Nome_Historia_de_Usuario [Diretório do Sistema no SVN]\Analise Planilha de PF Desenvolvimento [Nome do Sistema]_PFD_Número_OS [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Planilha de PF Manutenção [Nome do Sistema]_PFM_Número_OS [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Backlog [Nome do Sistema]_Backlog [Diretório do Sistema no SVN]\Analise Modelo Sintético de Casos de Uso [Nome do Sistema]_MSCU [Diretório do Sistema no SVN]\Analise Memória de Reunião [Nome do Sistema]_MR_aaaammdd [Diretório do Sistema no SVN]\Gerencia Casos de Teste [Nome do Sistema]_CT_Nome_Caso_de_Uso [Diretório do Sistema no SVN]\Testes Relatório de Cobertura de Testes [Nome do Sistema]_RCT_Número_Sprint [Diretório do Sistema no SVN]\Testes Relatório de Status [Nome do Sistema]_RS_ddmmaaa [Diretório do Sistema no SVN]\Gerencia\Status_Report Avaliação do Sprint [Nome do Sistema]_AS_Número_Sprint [Diretório do Sistema no SVN]\Gerencia Procedimento de Implantação [Nome do Sistema]_PI_Número_Sprint [Diretório do Sistema no SVN]\Gerencia Solicitação de Mudança [Nome do Sistema]_SM_N* [Diretório do Sistema no SVN]\Gerencia Ordem de Serviço [Nome do Sistema]_OS_Número_Sprint [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Documento de Requisitos para Manutenção [Nome do Sistema]_DRM [Diretório do Sistema no SVN]\Analise Planilha de Pontos de Função [Nome do Sistema]_APF_ANO_Número_OS [Diretório do Sistema no SVN]\Gerencia Documentação Técnica da Manutenção [Nome do Sistema]_DTM [Diretório do Sistema no SVN]\Analise Lista Não-conformidades (Visão Cliente) [Nome do Sistema]_LNC_Número_OS [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Lista Não-conformidades (Visão TI) [Nome do Sistema]_LNTI_Número_OS [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Lista de Mudanças [Nome do Sistema]_LM_Número_OS [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Controle Integrado de Mudanças [Nome do Sistema]_CIM_Número_OS [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Metodologia de Gestão e Desenvolvimento de Sistemas 60/61

191 Check-list da Ordem de Serviço [Nome do Sistema]_CLOS_Número_OS [Diretório do Sistema no SVN]\Gerencia\Ordem_Servico Metodologia de Gestão e Desenvolvimento de Sistemas 61/61

192 Guia de Escrita de Caso de Uso Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

193 Histórico de Revisões Data Versão Descrição Autor 15/06/ Elaboração da proposta do Guia de Escrita de Caso de uso 21/06/ Finalização da proposta do Guia de Escrita de Caso de uso 23/06/ Ajustes após a revisão interna da equipe EP. Luciana Barros Luciana Barros Luciana Barros 10/05/ Adequação a MGDS 2.0 Luciana Barros Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

194 Sumário 1 Introdução O que é especificação de caso de uso? Aplicação do caso de uso na metodologia do INEP Seções da especificação do caso de uso... 4 Boas práticas... 9 Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

195 1 INTRODUÇÃO Este documento tem como propósito apresentar uma sugestão para a padronização de escrita para a especificação do caso de uso, visando a disciplinar as equipes de projeto, internas e externas, a usarem a mesma linguagem para facilitar e agilizar o processo do desenvolvimento. As definições a seguir são aderentes às melhores práticas de mercado e adequadas à Metodologia de Gestão e Desenvolvimento de Sistemas do INEP. Este documento está organizado com as definições dos itens e exemplos práticos para o template de caso de uso disponível como um artefato opcional para a forma de registro do requisito na metodologia do órgão. 2 O QUE É ESPECIFICAÇÃO DE CASO DE USO? A especificação de caso de uso descreve o comportamento do sistema sob diversas condições, conforme a visão do cliente ou envolvido (stakeholders). Diferentes seqüências de comportamentos ou cenários podem surgir dependendo das requisições particulares solicitadas e das condições que cercam tais requisições, as quais devem ser escritas uma a uma. A especificação de caso de uso é fundamentalmente, uma forma textual, embora possa ser escrita usando fluxogramas ou português estruturado. Os casos de uso servem como meio de comunicação e representação das funcionalidades do sistema. Portanto, o texto simples é sempre a melhor escolha. 3 APLICAÇÃO DO CASO DE USO NA METODOLOGIA DO INEP Conforme previsto na metodologia do órgão, sua necessidade de uso será definição da equipe técnica em conjunto com o gestor, visando a atender a necessidade do projeto quanto ao prazo, custo e recursos. Podemos verificar no item 6 conjunto de artefatos da MGDS SEÇÕES DA ESPECIFICAÇÃO DO CASO DE USO 4.1 Breve descrição A descrição do caso de uso deve refletir sua finalidade e deve consistir de um texto que reflita a proposta central do caso de uso de forma clara e completa. A descrição do caso de uso deverá evidenciar se o caso de uso é Abstrato. Quando essa evidência não ocorrer o caso de uso será classificado como Concreto. Para a APF fica fácil identificar esta consulta implícita. Exemplo: Este caso de uso é uma extensão do caso de uso Pesquisar escola. Para cadastrar uma nova escola é necessário realizar uma pesquisa anterior garantindo assim um cadastro único para cada escola. O cadastro da escola nova contempla a inclusão e alteração dos dados de identificação da escola, geração do código INEP e código de desbloqueio da escola. 4.2 Atores Nesta seção deve ser abordada a definição e a responsabilidade de pessoas ou entidades envolvidas na realização das atividades descritas no documento. Exemplo: Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

196 Usuário INEP é um ator do tipo humano que possui acesso às escolas de todas as redes dos municípios pertencentes a todos os estados brasileiros. Este ator necessita de acesso a Internet e deve ter perfil com permissão para cadastrar escola nova. Usuário Secretaria Estadual é um ator do tipo humano que possui acesso às escolas de todas as redes e municípios pertencentes ao estado a que está vinculado. Este ator necessita de acesso a Internet e deve ter perfil com permissão para cadastrar escola nova. 4.3 Pré-condições Uma pré-condição descreve o estado em que o sistema deve estar antes do caso de uso ser iniciado. Esse estado deve ser observável pelo usuário, porém não é o evento que inicia o caso de uso e pode ser considerada uma premissa. A informação em uma pré-condição somente deve ser incluída na especificação quando for aplicável. ATENÇÃO: Na situação em que uma pré-condição seja tratada em fluxo de exceção ou alternativo do mesmo, essa informação deverá deixar de ser registrada na seção de précondição. Exemplo: 1 - Não existir o cadastro da escola - Para que uma escola seja cadastrada como nova é preciso garantir que a escola não exista no banco de dados do sistema Educacenso. 4.4 Fluxo de eventos Esta seção é composta pelos fluxo principal, fluxo alternativo e fluxo de exceção, ou seja, todos os cenários devem ser contemplados nestes fluxos. O fluxo deverá definir claramente todos os seus possíveis pontos de entrada, bem como seu ponto de saída. No último passo do fluxo deve-se deixar claro que o caso de uso é finalizado. Cada passo deve ser terminado com ponto e vírgula e no último passo deve-se colocar o ponto final. ATENÇÃO: Os passos do fluxo que referenciam os fluxos de exceção e os alternativos são excludentes entre si. Ou seja, no passo em que houver a referência FA e FE, ou o sistema executa o decrito no passo que contém a referência OU executa o FA ou FE. Por isso, não deve ser usado os termos condicionais: caso, se e quando nos passos. Um caso de uso pode ser abstrato ou concreto. O caso de uso concreto é iniciado por um ator e constitui fluxo completo de eventos. "Completo" significa que uma instância do caso de uso executa a operação inteira chamada pelo ator. O caso de uso abstrato propriamente nunca é instanciado. Os casos de uso abstratos são incluídos em, se estendem para, ou generalizam outros casos de uso. A distinção entre os dois é importante porque são os casos de uso concretos que os atores "verão" e iniciarão no sistema. 4.5 Fluxo Principal O fluxo principal é o caminho feliz da funcionalidade, ou seja, os passos consistentes para atingir o objetivo do caso de uso. Deste fluxo saem os fluxos alternativos e os de tratamento de erros, os fluxos de exceção. É importante conter um título que o identifique claramente e a seqüência ser numerada para os passos. Para referenciar um ponto de saída ou entrada, deve ser usado o termo PASSO e não item do fluxo referido. Exemplo: Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

197 Este fluxo tem início quando o sistema identifica que o ator selecionou a opção cadastrar escola nova. P1 - O sistema apresenta para preenchimento as seguintes informações de identificação da escola: Situação de funcionamento. Ano letivo: início Ano letivo: Término (previsão) Nome da escola CEP [RN05] Endereço Número Complemento Bairro UF Município Distrito DDD Telefone Telefone público (1) Telefone público (2) Fax Endereço eletrônico ( ) Código do Órgão Regional de Ensino Nome do Órgão Regional de Ensino Para a APF fica clara a repetição dos campos, e conforme regra do CPM conta-se somente 1(um) TD. Dependência administrativa (Federal, Estadual,Municipal e Privada) Localização/ Zona da escola (Urbana e rural) CNPJ da Unidade executora (pública ou privada filantrópica) Categoria da escola privada (Particular, comunitária, confessional e filantrópica) Conveniada com o poder público (Estadual, municipal) Número do registro no CNAS Número de certificado de entidade beneficente de assistência social - CEBAS Mantenedora da escola privada Número do CNPJ da escola privada Regulamentação /Credenciamento no conselho ou órgão municipal, estadual ou federal de educação (Sim, em tramitação e não) Dados para Autenticação: Nome do diretor/ responsável CPF do diretor / responsável Cargo do diretor / responsável Endereço eletrônico do diretor / responsável P2 - O ator preenche as informações para o cadastro da escola e seleciona a opção que permite salvar as informações. (E1); (E2); P3 - O sistema registra as informações inseridas e verifica se todos os dados do cadastro da escola são válidos conforme as regras [RN01], [RN02] e [RN03]. P4 - O sistema apresenta as seguintes informações para visualização: Mensagem informando que a escola foi cadastrada com sucesso conforme MSG012. O código da entidade no INEP O código de desbloqueio. P5 - O caso de uso é encerrado. 4.6 Fluxo Alternativo O fluxo alternativo é aquele que o sistema identifica que o ator adotou outro caminho, opcionalmente, diferente do caminho feliz. São aquelas situações em que exista desvio do caminho definido pelo fluxo principal; nestas ocasiões, devem-se utilizar a abordagem de fluxo alternativo. Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

198 Cada fluxo alternativo deverá conter um título que o descreva de forma correta e clara. Para esses fluxos opcionais ou alternativos recomenda-se descrever cada subfluxo em um suplemento separado da seção do comportamento normal. Esse procedimento é obrigatório nos seguintes casos: Subfluxos que ocupam um grande segmento de um determinado fluxo principal. Qualquer subfluxo que possa ser executado em vários intervalos do mesmo fluxo de eventos. IMPORTANTE: Não utilizar termo condicional para iniciar um fluxo. A condição é definida no momento da referencia do fluxo que o chama e é intrínseca a sua existência. Exemplo: Não se aplica. (para esta funcionalidade do UC de exemplo) Estrutura: FAn - <nome do fluxo> No passo X.x do fluxo a, o sistema verifica/ identifica que... An.1 - O ator... An.2 - O caso de uso retorna ao passo X.1 do fluxo a. 4.7 Fluxo de Exceção Abrangem as situações de eventos incomuns ou excepcionais. As exceções são subfluxos do caso de uso que não é compatível com o comportamento aceitável pelo cliente (fluxo principal); nestes casos, deve-se utilizar a abordagem de fluxo de exceção. Cada fluxo de exceção deverá conter um título que o descreva claramente. Um fluxo de exceção descreve os tratamentos das exceções surgidas nos fluxos principal e alternativo, que resultem na interrupção do cenário de sucesso esperado. Os eventos de exceção estão relacionados com a violação de regras de negócio e regras de integridade do sistema. Algumas possíveis situações: Preenchimento inválido de valores, validação de regras de preenchimento, comparação de campos; impossibilidade de exclusão de registros por estarem referenciados em outras entidades. IMPORTANTE: Para o fluxo de exceção também não se deve utilizar termo condicional para iniciar um fluxo. A condição é definida no momento da referencia do fluxo que o chama e é intrínseca a sua existência. Exemplo: E1 - Data inválida No passo P3 do fluxo principal, o sistema identifica que foi informada uma data inválida conforme o calendário anual nacional. E1.1 - O sistema exibe a mensagem MSG03 para informar que a data é inválida. E1.2 - O caso de uso retorna ao passo P2 do fluxo principal. E2 - Campos obrigatórios não informados No passo P3 do fluxo principal, o sistema identifica que pelo menos um campo obrigatório não foi informado. E2.1 - O sistema exibe a mensagem MSG04 para informar que o campo deve ser informado. E2.2 - O caso de uso retorna ao passo P2 do fluxo principal. Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

199 4.8 Pós-condições A pós-condição descreve os possíveis estados que o sistema deve estar após a finalização do caso de uso. Ao fazer uso deste recurso em casos de uso que possuem pontos de extensão, é preciso garantir que os passos definidos no caso de uso de extensão não violem a póscondição definida. Este tipo de informação somente deve ser incluído na especificação, quando aplicável. Caso não exista pós-condição, sugere-se utilizar: Não se aplica. OBS.: A pós-condição deve ser relevante e não o objetivo do caso de uso. A pós-condição é usada para reduzir a complexidade e melhorar a compreensão do fluxo de eventos do caso de uso. 4.9 Pontos de extensão Sendo um caso de uso base, indicar a existência do relacionamento de extensão nesta seção, do documento. Descrever a ação de um caso de uso chamar outro caso de uso. O ponto de extensão (PE) deve se comportar como um fluxo alternativo, ou seja, o caso de uso base (chamador) deve ser completo em si mesmo, o que significa que deve ser compreensível e fazer sentido sem nenhuma referência a extensões. Exemplo: Não se aplica. Estrutura: PEx Nome do caso de uso de extensão <Breve descrição apresentando também o ponto onde o ponto de extensão é chamado no caso de uso> 4.10 Requisitos Especiais Nesta seção devem ser descritas as informações pertinentes aos requisitos de negócios deste caso de uso. Ou seja, aqueles requisitos que não são abordados pelo fluxo de eventos. Esses requisitos provavelmente serão não-funcionais e influenciarão o modelo do design. Pode ser organizado em categorias como: usabilidade, confiabilidade e desempenho, mas geralmente são tão poucos que esses agrupamentos não são particularmente úteis. Esta seção deve ser utilizada para uma particularidade da funcionalidade em questão. Desta forma, não haverá replicação das informações contidas no documento de arquitetura. Exemplo: O tempo de efetivação do cadastro da escola nova deve ser de 2 segundos e disponibilizado automaticamente na base de dados para consulta e alteração das informações. Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

200 BOAS PRÁTICAS Cada passo de um fluxo deve descrever uma interação completa do ator ou do sistema: o Usar: 2. O ator informa dados do funcionário e aciona a opção para Inserir. o NÃO usar: 3. O ator informa dados do funcionário 4. O ator aciona a opção para Inserir. Usar voz ativa: o Usar: O ator informa dados do funcionário. o NÃO usar: Os dados de funcionário são informados pelo ator Generalizar o nome do ator ao descrever o passo, não utilizar o nome da função que ele ocupa no processo, por exemplo: o Usar: O ator informa dados do funcionário. o NÃO usar: O Gerente informa dados do funcionário. Não usar termos técnicos ou que se refiram à interface: o Usar: Solicita, lista, seleciona, inicia, especifica, envia, escolhe, exibe, apresenta, informa. o NÃO usar: Arrasta, formulário, fecha, abre, clica, drop-down, botão, combobox, pop-up, barra de rolagem, browse, janela, tela. Não usar termos que se refiram à arquitetura ou a forma de implementação, o foco deve sempre estar no comportamento. Como definir comportamentos repetitivos? Exemplo: O ator pode adicionar e remover disciplinas para o aluno até selecionar a opção de Salvar. Na descrição dos passos usar sempre os verbos no presente. Quando devemos usar casos de uso de extensão (extend)? Recomenda-se que, sempre que possível, se evite os relacionamentos de extensão. Como regra geral, deve-se dar preferência a atualizar a seção "Fluxos alternativos", em vez de criar relacionamentos complexos entre casos de uso. Ou seja, é preferível adicionar um cenário extra na seção "Fluxos alternativos" a criar casos de uso separados. Estes deverão ser criados quando for um comportamento complexo e utilizado por mais de um caso de uso para que valha a pena o tipo de relacionamento. Na especificação do caso de uso de extensão (o estendido) é sugerido para descrição inicial do fluxo de evento: "Este caso de uso é uma extensão do(s) caso(s) de uso [nome do(s) caso(s) de uso]. Quando for iniciado pelo ator ou como extensão de outro caso de uso: Este caso de uso inicia quando [descrever a condição que inicia do caso de uso] ou quando é uma extensão do(s) caso(s) de uso [nome do(s) caso(s) de uso]. Quando for Include - Na especificação do caso de uso base, para indicar a existência do relacionamento de inclusão na estrutura dos fluxos de eventos do caso de uso é sugerido utilizar o indicativo no passo que ocorre, por exemplo: P2 O sistema exibe as informações dos cursos que o aluno está associado incluir caso de uso Apresentar Cursos. Na especificação do caso de uso de inclusão (o incluído), listar na seção de Atores, todos os atores envolvidos no(s) caso(s) de uso base (aquele que o chama). É sugerido utilizar no texto "Este caso de uso é uma inclusão do(s) caso(s) de uso [nome do(s) caso(s) de uso]. Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

201 Nível de detalhamento (abstração) dos fluxos o caso de uso é descrito na visão do usuário, de forma simples, completa e clara. Para isso, é necessário utilizar uma linguagem adequada para o entendimento comum entre equipe técnica e usuário. Concentre-se na descrição do que é feito no caso de uso, e não em como problemas específicos e internos do sistema devem ser solucionados, os modelos de objetos existem para esta finalidade. Descreva apenas os fluxos que pertencem ao caso de uso, e não o que ocorre em outros casos de uso utilizados paralelamente a esse. Jamais repetir fluxos que ocorrem em outro caso de uso. Não mencione os atores que não se comunicam com o caso de uso em questão. Não insira excesso de detalhes ao descrever a interação do caso de uso com os atores, o que levaria a descrição técnica. As informações, dados trocados entre ator e sistema devem ser explícitos. Use os termos do glossário comum e considere as seguintes questões ao redigir o texto: Use vocabulário claro e direto. Não use termos complexos quando um termo simples pode ser usado. Crie frases curtas, objetivas e concisas. Evite advérbios, como muito, mais, bastante e outros semelhantes. Use a pontuação correta. Evite frases compostas. Metodologia de Gestão do Desenvolvimento de Sistemas - MGDS 2.0

202 GUIA DE ARQUITETURA JAVA WEB e PHP Guia_Arquitetura.doc 1

203 Histórico de Revisões Versão Dt. Data Responsável Motivação /05/2009 Gabriel Viragine / Thiago da Mata / Evandro Torezan / Victor Luiz Soares Vitorino/ Fábio Divino /02/2010 Thiago da Mata / Victor Luiz Soares Vitorino Elaboração do Guia de Arquitetura. Atualização na Parte II trata sobre a Arquitetura PHP /03/2010 Gabriel Viragine / Daniel Resende Refinamento da Parte I trata sobre a Arquitetura Java. Guia_Arquitetura.doc 2

204 1. Introdução 1.1. Finalidade Este documento pretende apresentar uma visão geral das arquiteturas de sistemas Java e PHP utilizadas no Inep. Ele deve ser usado como uma referência para construção de novos sistemas e fonte de consultas em relação ao padrão de arquitetura utilizada no Inep. O mesmo também deve servir como insumo para a elaboração do documento de arquitetura do projeto, artefato descrito na MGDS (Metodologia de Gestão e Desenvolvimento de Sistemas) Escopo O documento aplica-se aos sistemas do Inep ( desenvolvidos internamente ou externamente), em que as linguagens de programação sejam Java e PHP Evolução deste guia Este guia foi construído baseado nas experiências dos projetos anteriores do Inep e assim sendo pode e deve ser continuamente adequado / adaptado conforme as lições aprendidas e as evoluções tecnológicas que surgirem no mercado. 2. Representação da Arquitetura A arquitetura de um sistema é o alicerce onde se funda o software. A partir dos modelos, camadas, abstrações e frameworks apresentados e sugeridos, o projetista e o desenvolvedor do sistema têm uma visão geral, técnica e conceitual da aplicação que será construída. A arquitetura define, entre outras coisas, onde implementar regras de negócios, onde e como persistir informações e as tecnologias que devem ser utilizadas. Cabe aos projetistas e desenvolvedores adaptar os requisitos funcionais do sistema às definições da arquitetura. Não faremos referência a projetos específicos, já que seu objetivo é definir uma arquitetura geral de desenvolvimento Java e PHP. Não é raro ainda, que alguns projetos venham a necessitar de mais camadas do que as aqui descritas, mas essa decisão deve ser feita juntamente com a equipe técnica do Inep, preferencialmente no início do projeto. O Guia de Arquitetura será divido em duas partes, sendo elas: Parte I Arquitetura Java Web; Parte II Arquitetura PHP. Guia_Arquitetura.doc 3

205 3. Metas e Restrições da Arquitetura A arquitetura aqui definida, prima pela simplicidade e produtividade, fazendo uso de tecnologias que permitam a criação de softwares robustos, confiáveis e de fácil manutenção. Apesar das camadas descritas no documento, serem possíveis de serem implementadas em vários frameworks, o framework recomendado para o desenvolvimento das aplicações PHP é o Zend Framework (versão homologada pelo Inep), tendo em vista a maturidade desse framework no meio empresarial. Para aplicações Java acessadas via browser (aplicações WEB) deve ser utilizado o MECSeam, framework do Inep para aplicações WEB, baseado no Framework Seam (versão homologada pelo Inep). Ainda não possuímos um Framework para desenvolvimento de aplicações Desktop, caso exista alguma demanda para este tipo de aplicação, entre em contato com a equipe técnica do Inep. Por padrão, o Inep utiliza a versão 1.6 do Java (JEE). No desenvolvimento de WebServices, o padrão e-ping deve ser respeitado, segue link de referência deste padrão: Guia_Arquitetura.doc 4

206 Parte I Arquitetura Java Web Guia_Arquitetura.doc 5

207 1. Visões 1.1. Visão Lógica Os sistemas WEB estão logicamente divididos em 4 camadas com responsabilidades distintas, sendo elas: Apresentação, Controle, Negócios e Persistência. Os sistemas utilizam em sua implementação o framework MECSeam, extensão do framework Seam (http://seamframework.org/). Os usuários, através de algum navegador Internet (browser), acessam as páginas HTML geradas pelo servidor ao processar os arquivos XHTML da camada de apresentação, e executam as operações que desejam. As operações são submetidas às Actions, que reúnem as informações necessárias e as envia aos Managers. Os Managers realizam a operação solicitada acessando a camada de persistência para consulta ou persistência de dados. O JPA, através do provider selecionado (Hibernate, Toplink, etc.), usando as entities mapeadas, acessa o banco de dados e executa as operações solicitadas. Nas consultas, entities ou listas de entities são retornadas e tratadas pelas camadas intermediárias, que executam regras de negócios e preparam novas páginas que são enviadas aos navegadores. Guia_Arquitetura.doc 6

208 Camada de Apresentação A camada de apresentação representa o front-end da arquitetura. Seu núcleo é constituído por arquivos XHTML, que contêm componentes MECSeam, utilizando as tecnologias: JSF, Facelets, RichFaces, e Seam. Tecnologias da camada de apresentação do MECSeam: JSF - Java Server Faces Facelets https://facelets.dev.java.net/ RichFaces Seam Camada de Controle A camada de controle trabalha como ponto focal para tratamento de requisições vindas da camada de apresentação e provê acesso à camada de negócios. É implementada por meio de componentes Seam Javabeans denominados Actions. Tecnologias da camada de controle do MECSeam: Camada de Negócio JSF - Java Server Faces Seam Na camada de negócio são implementadas as regras de negócio do sistema. É composta por componentes Seam Javabeans denominados Managers. Tecnologias da camada de negócio do MECSeam: Seam Guia_Arquitetura.doc 7

209 Camada de Persistência Na camada de persistência ocorre a troca de informações entre a aplicação e o repositório de dados. É composta por entity beans anotados que representam tabelas do banco de dados. Tecnologias da camada de persistência do MECSeam: Java Persistence API JPA Seam Visão de Implantação Os sistemas são executados em servidores de aplicações JEE ( Java Platform Enterprise Edition) e acessam bases de dados corporativas. 2. Detalhamento da Arquitetura 2.1. Servidor de Aplicações JEE Por padrão, o Inep utiliza o JBoss Application Server como servidor de aplicações JEE, versões 4.2_CP01 e a 4.3_CP06. Novas versões poderão ser utilizadas desde que previamente homologadas pelo Inep. Guia_Arquitetura.doc 8

210 2.2. IDE de Desenvolvimento Por padrão, o Inep utiliza o Eclipse com o plugin Jboss Tools (http://www.jboss.org/tools/), o qual deverá ser utilizado a versão previamente homologada pelo INEP Criação inicial do projeto Para a criação de um novo projeto Seam deve ser utilizado o wizard do JBoss Tools Empacotamento de Aplicações As aplicações devem ser empacotadas no formato WAR (Web Archive). Se a aplicação fizer uso de EJBs empacotados como JAR (Java Archive) e outras tecnologias que necessitem de empacotamento diferente de WAR, os pacotes necessários devem ser empacotados em um EAR (Enterprise Archive). O Seam provê mecanismos para criação de agendamentos de tarefas (tasks schedulers), porém, caso schedulers sejam necessários, deve-se usar o mecanismo fornecido pelo Jboss Server que permite controle pelo deployer (parada, início, mudança de horário, etc). Segue link de referência: Publicação/Configuração das Aplicações O Inep utiliza o Apache Continuum ( como ferramenta de integração contínua, onde o empacotamento e publicação das aplicações no ambiente de desenvolvimento são automatizados por esta ferramenta. Os scripts devem ser criados utilizando o Apache Maven ( ou o Apache Ant (http://ant.apache.org/). Preferencialmente deve-se utilizar o Maven. Para a configuração das aplicações, não esquecer de alterar os parâmetros dos seguintes arquivos: Guia_Arquitetura.doc 9

211 web.xml: Parâmetro Valor Observação facelets.refresh_period -1 Indica que o Facelets não deve tentar recarregar páginas modificadas. A não utilização deste parâmetro gera um erro intermitente na aplicação quando a data do sistema está atrasada em relação à data do arquivo EAR publicado. Comente este parâmetro em ambiente de desenvolvimento para hot deploy das páginas. facelets.development false components.xml: Elemento core:init Atributo/Valor debug="false" 2.6. Estrutura de Diretórios Pacotes de Código Fonte Java A palavra sistema, na lista abaixo, deve ser substituída pelo nome do sistema em questão. Lembrando que nomes de pacotes, de acordo com a Java Code Conventions, devem possuir apenas caracteres minúsculos. (http://java.sun.com/docs/codeconv/html/codeconventions.doc8.html#367). src br.gov.inep.sistema.action br.gov.inep.sistema.entity br.gov.inep.sistema.manager Guia_Arquitetura.doc 10

212 Arquivos da WEB O diretório WebContent é a base para a criação do arquivo WAR. Dentro deste diretório é obrigatória a presença do diretório WEB-INF. Veja exemplo abaixo desta estrutura de diretórios. Guia_Arquitetura.doc 11

213 Visão dos Componentes Estruturais Detalhamento da Camada de Apresentação Serão utilizados componentes JSF/Facelets/RichFaces/Seam e componentes customizados utilizando Facelets (MECSeam). A customização de componentes tem por objetivo substituir os componentes específicos das bibliotecas supracitadas de forma a abstrair os componentes utilizados e padronizar a utilização dos mesmos. A referência básica para a criação desses componentes pode ser encontrada no endereço: As entidades (Entities), que compõem a camada de persistência da aplicação, serão usadas como DTOs (Data Transfer Object) quando necessário. Assim, serão utilizados diretamente na camada de apresentação para capturar entrada de dados do usuário. Caso necessite de algum atributo que não faça parte de sua entidade, como por exemplo: intervalos de datas e telas de pesquisa, deverão ser criados atributos transientes ou como um atributo de sua classe Action. O Seam inovou o compartilhamento de objetos através do contexto de conversação, onde os objetos podem ser compartilhados entre as camadas com as Guia_Arquitetura.doc 12

214 private Usuario usuario = new private FacesMessages facesmessages; A camada de apresentação irá comunicar-se (invocar ações) com a camada de controle diretamente com componentes da camada de controle (Actions). Exemplo: <h:commandbutton value="salvar" action="#{minhaaction.meumetodo()}"/> Se o método tiver que submeter um objeto que está presente na camada de apresentação, ele pode ser diretamente referenciado. Exemplo: <h:commandbutton value="salvar" action="#{minhaaction.meumetodo(objeto)}"/> O nome dos formulários (páginas) da camada de apresentação deve seguir a convenção de nomes da Sun para JSP. (http://java.sun.com/developer/technicalarticles/javaserverpages/code_convention/). Caso sua aplicação necessite de internacionalização (i18n) para a camada de apresentação esta informação deverá fazer uso de um arquivo específico para cada idioma. (http://docs.jboss.com/seam/2.0.2.sp1/reference/en-us/html_single/#d0e9126). Arquivos com conteúdo estático tais como: Javascript, CSS e imagens deverão ficar no servidor de conteúdo estático corporativo ( seguindo a organização de diretórios definida para o servidor. Exemplo: colocar os arquivos de imagens no diretório imagens Detalhamento da Camada de Controle A camada de controle deve ser implementada com componentes Seam JavaBeans e deve seguir a seguinte nomenclatura: 1. Para a classe: NomeDaClasseAction (ex: PesquisaUsuarioAction) ; 2. Para o nome do componente Seam: deve ser utilizado o mesmo nome da classe com Guia_Arquitetura.doc 13

215 a primeira letra em minúsculo (ex: pesquisausuarioaction); A escolha do escopo deverá ser adequada ao propósito do componente. Vale ressaltar que a escolha do escopo influencia de forma direta o consumo de memória e desempenho da aplicação. De maneira geral: Se o componente controlador for servir apenas a uma requisição, deve-se utilizar o escopo Event; Se o componente controlador for servir a várias requisições de uma mesma página, deve-se utilizar o escopo Page; Se o componente controlador for controlar múltiplas páginas, deve-se utilizar o escopo de conversation. (Observação: Sempre que for utilizado o escopo de conversation lembrar de finalizar a conversation quando a mesma não for mais necessária); Se o componente for controlar múltiplas páginas para múltiplas conversations, deve-se utilizar o escopo Session; Se o componente for usado por todos os usuários do sistema, sem alterações, deve-se utilizar o escopo Application. Os componentes injetados nas Actions que serão necessários na camada de negócios devem ser passados por parâmetro. Os componentes de negócio serão disponibilizados nas Actions através da injeção dos Managers. Os Managers serão anotados com a sendo assim, basta utilizarmos a para injetarmos o componente de negócio no componente controlador (Action). Exemplo de componente controlador (Action) com injeção de componente de public class MinhaAction private ComponenteManager componentemanager;... } Detalhamento da Camada de Negócio As classes/componentes Seam devem seguir a seguinte nomenclatura: Guia_Arquitetura.doc 14

216 1. Para a classe: NomeDaClasseManager (Exemplo: EstudanteManager); 2. Para o nome do componente Seam: deve ser utilizado o mesmo nome da classe com a primeira letra em minúsculo (Exemplo: estudantemanager). Os Managers devem ser criados para entidades fortes, que representam pontos principais da aplicação. Exemplo: AlunoManager. Não se deve utilizar EJBs, a não ser que sejam realmente necessários, ou seja, havendo acesso remoto de outras aplicações ou de clientes desktop. Assim, a camada de negócio deve ser implementada com componentes Seam POJO, que dão maior agilidade no desenvolvimento e facilidade de manutenção. Deve-se utilizar transações gerenciadas pelo Seam, que funcionam da mesma forma para componentes EJB ou POJOs. As Actions podem acessar quantos Managers forem necessários. Assim, VisualizarAlunoAction poderia recorrer ao AlunoManager para obter informações de alunos, e EscolasManager para obter os dados das escolas. O uso de componentes injetados na camada de negócio deve ser evitado. As Actions devem se comunicar com as Managers através dos métodos de acesso, passando os parâmetros necessários. O componente de negócio deve ser anotado para que no momento de sua utilização por componentes da camada de controle, não seja necessária a utilização da opção (create=true) na anotação de Exemplo de classe/componente public class EstudanteManager { public Estudante recuperapornome(string nome) { return (Estudante) entitymanager.createnamedquery( "estudante.recuperapornome").setparameter("nome", nome).getsingleresult(); } } Detalhamento da Camada de Persistência Na camada de persistência, são utilizados Entity Beans ( JPA) (http://java.sun.com/javaee/technologies/persistence.jsp). Sempre que necessário (no caso do banco de dados já existir e o modelo de objetos seguir o modelo de dados relacional) será realizada a engenharia reversa do banco de dados utilizando a ferramenta JBoss Tools ( e customizados os atributos das classes conforme o padrão de nomenclatura para classes/atributos vigente. Guia_Arquitetura.doc 15

217 Maiores detalhes sobre a utilização do JBoss Tools para a execução da engenharia reversa, podem ser encontrados no endereço: Todas as entidades do sistema devem estender a classe BaseEntity (MECSeam) sobrescrever o método getid() conforme descrito no exemplo que segue: public abstract class BaseEntity implements Serializable { protected Long id; public BaseEntity() { } public void setid(long id) { this.id = id; public boolean equals(object obj) { if (this == obj) return true; if (obj == null) return false; if (getclass()!= obj.getclass()) return false; final BaseEntity other = (BaseEntity) obj; if (id == null) { if (other.id!= null) return false; } else if (!id.equals(other.id)) return false; return true; public int hashcode() { final int prime = 31; int result = 1; result = prime * result + ((id == null)? 0 : id.hashcode()); return result; } public String tostring() { return this.getclass().getname() + "[id=" + id + "]"; } Guia_Arquitetura.doc 16

218 O propósito da classe BaseEntity é prover o atributo id e os métodos equals() e hashcode() para todas as entidades do sistema. Como atualmente a coluna no BD definida como Primary Key (PK) não é definida com o mesmo nome para todas as tabelas do BD, é necessário definir o método getid() para todas as entidades que estendem = public Long getid() { return id; } Exemplo de classe public class Aluno extends BaseEntity { } private static final long serialversionuid = public Long getid() { return id; }... Após a criação da Entidade, serão definidas regras de validação com a utilização do framework de validação Hibernate Validator (http://validator.hibernate.org/). Além das anotações padrões do Hibernate Validator (http://www.hibernate.org/hib_docs/validator/reference/en/html_single/#validatordefineconstraints-builtin), serão utilizadas anotações personalizadas (MECSeam) (http://www.hibernate.org/hib_docs/validator/reference/en/html_single/#validatordefineconstraints-own) como por Quando da criação de Hibernate Validators personalizados cujo valor a ser validado é do tipo String, devemos estender a classe AbstractHibernateStringValidator que já provê controle básico comum a validação de Strings e implementar o método validate (String valoravalidar). Exemplo: public abstract class AbstractHibernateStringValidator<A extends Annotation> implements Validator<A> { Guia_Arquitetura.doc 17

219 public void initialize(a Annotation) { } public boolean isvalid(object value) { if (isempty(value)) { return true; } if (!(value instanceof String)) { return false; } } return validate(value.tostring()); private boolean isempty(object value) { if (value == null) { return true; } if (value instanceof String && (value.tostring()).trim().length() == 0) { return true; } } return false; } protected abstract boolean validate(string value); Anotação { ElementType.METHOD, CPF { } String message() default "CPF inválido"; Classe de validação: public class CPFValidator extends AbstractHibernateStringValidator<CPF> { public boolean validate(string cpf) { return CPFUtils.validaCPF(cpf); } Guia_Arquitetura.doc 18

220 Quando a informação a ser validada não for do tipo String, deve-se criar a classe abstrata no padrão da classe AbstractHibernateStringValidator e estendê-la da mesma maneira descrita acima. Maiores detalhes sobre o framework Hibernate Validator podem ser obtidos em: Vale lembrar que as anotações definidas nas Entidades podem (e devem) ser utilizadas diretamente na camada de apresentação, maiores detalhes dessa abordagem pode ser vistos em Guia_Arquitetura.doc 19

221 Parte II Arquitetura PHP Guia_Arquitetura.doc 20

222 1. Visão Lógica 1.1.Visão Cliente Servidor Os sistemas PHP têm foco exclusivo para sistemas Web. O uso de PHP em aplicações desktop, apesar de existir no PHP-GTK, é recomendado apenas para uso experimental. Os sistemas Web que trabalham em cima do protocolo HTTP funcionam sobre a arquitetura Cliente Servidor. Os usuários, fazendo uso do navegador ou browser, interagem com o sistema com requisições HTTP que são processadas pelo Servidor. O servidor recebe a requisição do usuário e executa um evento no sistema. Após executar o evento, Guia_Arquitetura.doc 21

223 o sistema monta dinamicamente uma página XHTML baseada na resposta do evento. Esta página é retornada ao usuário como resultado da requisição HTTP. O Navegador, ao processar os arquivos XHTML, acessa também as imagens, as folhas de estilo CSS, os arquivos de eventos client-side Javascript para montar uma tela que possibilita ao usuário novas interações com o sistema. As aplicações Web, ganharam uma nova qualidade de interação utilizando, em conjunto com as comunicações síncronas, comunicações assíncronas. Essas páginas que fazem o uso de comunicação assíncrona, buscando gerar maior interatividade são chamadas de RIA Rich Internet Applications ou Internet Rica. Guia_Arquitetura.doc 22

224 Guia_Arquitetura.doc 23

225 Ao se utilizar Javascript para fazer páginas ricas, as interações assincronas devem ser geridas pelo próprio Javascript. Esse método de comunicação é conhecido como Ajax - Asynchronous Javascript And XML. Fazendo uso deste tipo de tecnologia é possível desenvolver aplicações com as vantagens de uma aplicação Web e com qualidade de interação próxima às aplicações desktop Visão Cliente Comunicação por páginas XHTMLs Na comunicação por páginas XHTMLs, as informações disponíveis na máquina do cliente são as páginas XHTMLs, os estilos CSS as imagens e os scripts Javascript. Esses elementos se referenciam entre si de modo a criar uma página Web onde o usuário possa vir a interagir. A página XHTML deve se concentrar em mostrar a informação. As regras de estilos devem ficar nas folhas de estilo que são referenciadas pela página XHTML. O conteúdo Javascript deve se concentrar nos arquivos Javascript sendo as chamadas feitas no HTML. A informação na página deve estar organizada de maneira lógica e seqüencial. As folhas de estilo CSS podem auxiliar a mostrar na página apenas a informação relevante, a organizar a informação do XHTML de modo mais agradável e guiar a organização visual do usuário. O layout deve ser flexível a várias resoluções. O Javascript pode auxiliar em tornar o uso da aplicação mais rápido e intuitivo. Algumas interações podem ser previamente validadas pelo Javascript, evitando assim que requisições Guia_Arquitetura.doc 24

226 inconsistentes sejam feitas ao servidor. Como o processamento é local o tempo de resposta para tais requisições é mais rápido para o cliente. Filtros de campos obrigatórios, validação de CPF e CNPJ, confirmação de senha, s inválidos dentre outros filtros similares podem ser feitos em Javascript para melhorar a qualidade de interação e velocidade do sistema. O resultado dessas interações deve, sempre que possível, gerar mensagens amigáveis ao usuário do sistema. As folhas de estilos CSS e as bibliotecas de Javascript podem ser reaproveitadas por várias páginas do sistema economizando banda de rede e acelerando o tempo de carga das páginas pelo cliente, além de facilitar a padronização do estilo e do comportamento dos componentes do sistema Comunicação por Elementos XMLs não XHTMLs Alguns projetos demandam a criação de elementos que não se restringem aos componentes nativos do HTML (tabelas, listas, imagens, etc.). Para viabilizar a criação destes elementos, existem outras linguagens de marcação XML que provém diferentes formas de interação com o usuário. Dentre elas: o SVG para criação de apresentações vetoriais, VRML para criação de apresentações 3D e Flex para criação de apresentações em SWF. O Processamento do XML do Flex para a criação de um SWF deve ser feito no servidor, utilizando-se um interpretador SDK, sendo o SWF apenas enviado para o cliente Comunicação por Elementos não XMLs É possível, e muitas vezes necessária, a criação de elementos não XMLs para atender a demanda de alguns projetos. Algumas aplicações mais recentes utilizam o Canvas em Javascript para criação desses componentes de interação personalizados, mas esse recurso apresenta algumas restrições de compatibilidade em Navegadores Antigos. Para geração de outros tipos de arquivo, podem vir a serem necessárias outras funcionalidades, disponibilizadas com o uso de componentes desenvolvidos em PHP ou por meio de extensões, módulos compilados não nativos que podem ser integrados ao PHP, adicionando novas funcionalidades à linguagem. O uso de extensões tem a vantagem da velocidade de execução, da simplicidade da instalação e da independência de frameworks para funcionar. Em compensação, as extensões demandam uma adaptação do ambiente do servidor o que pode vir a acarretar problemas ao se colocar a Guia_Arquitetura.doc 25

227 aplicação em produção. Algumas extensões não funcionam em servidores Windows, outros exigem que alguma(s) aplicação (ões) seja (m) instalada (s) no servidor, etc. O uso de componentes apresenta a vantagem da flexibilidade, da clareza do funcionamento e da facilidade da manutenção e do desenvolvimento de novas funcionalidades. Em compensação os componentes em PHP costumam ser mais lentos que as extensões e tendem a apresentar uma dependência com algum Framework e com outros componentes em PHP. Algumas extensões foram incorporadas ao PHP em suas versões mais recentes, sendo então o seu uso recomendado em relação ao de componentes similares. Dentre as funcionalidades disponíveis em extensões PHP, vale ressaltar a geração de imagens pelo GD, geração de SWFs pelo Ming, controle de chaves de segurança com OpenSSL além dos plugins de Web Service necessários para o uso de Web Services. O XDebug é uma extensão muito útil para auxiliar ambientes de desenvolvimento mas não deve ser aplicado em ambientes de produção. Existem componentes desenvolvidos em PHP para a criação dos mais diversos formatos de saída. Para criação de PDFs, por exemplo existem o FPDF e o Html2Fpdf, dentre outros. Para criação de documentos Ms. Word, existe o LiveDocx, para criação de Planilhas Ms. Excel, o PHPExcel, etc. Muitos componentes podem ser encontrados em sites especializados em projetos de código aberto, dentre esses vale ressaltar o SourceForge, PhpClasses, Assembla, Zend Framework Components, dentre muitos outros. O uso de códigos de terceiros está sujeito a licença de uso desses códigos. Além disso, a responsabilidade pela qualidade do código utilizado é da empresa contratada, mesmo que não seja ela a criadora do mesmo. Ao utilizar um componente público a empresa contratada deve validar a qualidade do mesmo e assegurar o funcionamento do mesmo no ambiente de produção do projeto. A maioria dos componentes disponibilizados não apresenta nenhuma garantia do fabricante, sendo obrigação da equipe que o utilizar atestar e validar a qualidade do mesmo, assumindo assim os riscos do seu mau funcionamento Visão Servidor O servidor recebe as requisições do cliente através de uma mesma página PHP, também conhecida como bootstrap que, conforme os parâmetros da requisição encaminham para a controladora específica. A controladora, fazendo uso das demais camadas necessárias gera o XHTML resultante que é enviado ao cliente para que o navegador monte a página de resultado. Guia_Arquitetura.doc 26

228 2. Camadas Nos design orientado a objetos, uma camada é um grupo de classes que tem as mesmas dependencias de módulos, em outras palavras, é um grupo de componentes reutilizáveis que são utilizados em circunstancias similares, com propósitos similares. Camadas costumeiramente se organizam numa arvore hierárquica, baseada nas relações de dependência entre elas. As depedencias mais comuns entre as camadas são herança, composição e agregação, mas outros tipos de dependência também podem ser utilizados. Camadas é um padrão arquitetônico descrito em muitos livros, como por exemplo, Pattern-Oriented Software Architecture. A arquitetura em camadas geralmente encapsula a complexidade técnica de um software de modo independente à lógica de negócio e assim provendo um menor acoplamento entre as funcionalidades de negócio e a infra-estrutura técnica subjacente. Uma arquitetura em camadas contribui para o melhor desenvolvimento de um software, possibilitando o teste e detecção de erros nas camadas adjacentes. Este recurso isola os componentes da arquitetura e os protege contra falhas em outras camadas. Esta prática permite o desenvolvimento de aplicativos de software a serem mais eficazes, divididos em equipes, com cada equipe trabalhando em uma camada diferente simultaneamente. Guia_Arquitetura.doc 27

229 Arquitetura PHP em Camadas As camadas propostas para a arquitetura PHP são: Apresentação, Controladora, Segurança, Negócio, Entidade, Persistência, Banco de Dados, Visão e Template. Sendo as Camadas de Apresentação e Banco de Dados não são em PHP mas são aqui representadas para facilitar a compreensão das demais. Guia_Arquitetura.doc 28

230 Diagrama de Sequência das Camadas Guia_Arquitetura.doc 29

231 Diagrama de Comunicação das Camadas Guia_Arquitetura.doc 30

232 BPMn de Exemplo de Fluxo entre as Camadas Guia_Arquitetura.doc 31

233 Resumo das Camadas: Apresentação Camada que monta as requisições e as envia ao servidor. Pode ser uma submissão de um formulário HTML, ou uma requisição por Ajax, uma requisição HTTP feita por uma Applet Java ou um SWF, etc. Essa camada é executada no cliente e, assim sendo, não executa código PHP. Apesar disto é o resultado do evento na controladora PHP que monta a próxima apresentação para o cliente. Controladora Camada responsável por converter os parâmetros recebidos pela requisição em entidades do sistema, chamar os objetos de negócio adequados para a execução daquele evento e encaminhar o resultado da execução do evento para a camada de visão, de modo que essa possa montar a tela de resultado adequadamente. Negócio Camada responsável pela lógica de negócio da aplicação. O controle de fluxos, filtros, restrições, condicionais, etc. Os métodos de negócio podem fazer referencias entre si. A camada de negócio pode chamar a camada de persistência quando considerar necessário. Entidade Camadas das classes responsáveis por representar no mundo OO às representações significativas distintas, sejam ou não objetos físicos. As entidades têm pouca ou nenhuma lógica de programação com atributos acessíveis por getters e setter. São utilizados para trafegar as informações no sistema. Persistência Camada das classes que criam comandos de Banco de Dados a partir das Entidades. Também é responsável por converter o resultado de uma operação no banco de dados em uma ou mais Entidades. Visão Camada responsável por guardar as informações vindas da controladora para a montagem da página HTML e em montar a página HTML a partir dessas informações, utilizando o Template selecionado. Template Arquivos próximos de HTMLs com conteúdo dinamico que são utilizados pela Visão na criação das páginas XHTMLs resultantes. Segurança Camada responsável pelo controle de acesso às funcionalidades do sistema. Cada método da controladora pode informar qual é a permissão que ele requer. A segurança confere se o usuário tem tal permissão. Guia_Arquitetura.doc 32

234 Banco de Dados ou SGDB Programa externo acessado pela PHP que visa gerenciar o acesso, manipulação e organização dos dados utilizados pela aplicação. Recomenda-se o uso de alguma abstração para intermediar a comunicação entre o PHP e o Banco de Dados. Web Service Camada de Classes similares a controladoras mas que recebem as requisições de outros sistemas e retornam objetos e não telas Controladora Controladora é a camada que recebe as informações enviadas pelo sistema externo, converte-as em entidades dos sistemas e as envia para os objetos de negócio apropriados para o serviço desejado. Após isto, fazendo uso do retorno da operação, a controladora deve chamar a visão apropriada, interagindo com a mesma conforme necessário. A Controladora define qual será o Template utilizado pela visão para gerar a Apresentação desejada. A controladora pode também chamar a camada de segurança, para bloquear o acesso de usuário sem autorização. Guia_Arquitetura.doc 33

235 2.2. Negócio Guia_Arquitetura.doc 34

236 Uma camada de lógica de negócio (BBL) contém a lógica de negócio da aplicação que deve ser acessível e independente às outras camadas, tais como persistência ou apresentação. Ao fazer isso, a lógica da aplicação suporta melhor mudanças ou substituições reduzindo o impacto sobre as demais camadas. Apenas os métodos que se desejem disponíveis para o acesso externo devem ser públicos. Os métodos públicos devem, preferencialmente, receber e retornar Entidades ou Coleções de Entidades. As classes de negócio são classes estáticas que não contém atributos próprios Todos os objetos instanciados são entidades ou variáveis temporárias dos métodos, exclusivas de seu escopo. A camada de Negócio também é chamada de Processos de Negócio ou Atividades de Negócio. Guia_Arquitetura.doc 35

237 2.3. Entidade Guia_Arquitetura.doc 36

238 Uma entidade é algo que tem uma distinção, uma existência separada. Entidades são utilizadas em desenvolvimento de modelos de sistemas que mostram as comunicações e processos internos durante o processamento. Wikipédia As aqui chamadas de Entidades, são mais próximos de um Objeto de Transferência de Dados (DTO) ou Objeto de Valor (VO) do que de uma Entidade de Negócio (BE). Isto é, as Entidades visam à aplicação de um Padrão de Projeto onde esses objetos são o método pelo qual a informação trafega pelos subsistemas e camadas do software. São freqüentemente utilizados para fazer o mapeamento dos registros de tabelas do Banco de Dados. Algumas vezes, fazendo uso deste mapeamento, disponibilizam algumas operações padrões, fazendo chamadas as camadas de Persistência. Essa aplicação das Entidades é conhecida como Objeto de Acesso a Informação (DAO). As Entidades podem apresentar alguma lógica de negócio que possibilite o Padrão de Projeto de Carga Preguiçosa Lazy Load, a entrada de uma mesma informação por diferentes formatos e a saída de uma mesma informação por diferentes formatos além dos métodos padrões de chamada a persistência, se existirem Persistência Guia_Arquitetura.doc 37

239 A persistência de dados, na computação, refere-se ao armazenamento não-volátil de dados. ( ) Na Orientação a Objetos, chama-se de "objetos persistentes" aqueles que permanecem existindo mesmo após o término da execução do programa. Associados à persistência estão o gerenciamento dinâmico da memória e o armazenamento de objetos em bases de dados. Wikipedia A Persistência deve, a partir das Entidades, executarem os comandos necessários para que estas venham a ser persistentes. Isto é, gerar e executar os comandos SQL no Banco de Dados, para inserir, alterar e recuperar ( CRUD) as Entidades. Os comandos SQL criados devem utilizar abstração de Banco de Dados, onde a PDO é a atualmente recomendada, controle transacional, com o uso de Prepared Statement para evitar SQL Injection. As Classes desta camada devem ser estáticas e seus métodos, sempre que possível, devem receber Entidades como parametro e retornar Entidades como resultado. Guia_Arquitetura.doc 38

240 2.5. Visão Na arquitetura MVC a visão desenha o Modelo num formato apropriado para a interação com o usuário, tipicamente num formato apropriado para alguma interface com usuário. Várias visões podem existir de um mesmo modelo para atender a propósitos diferentes. Na arquitetura PHP proposta não existe a figura do Modelo pois este foi divido em Negócio e Entidade. O elemento necessário para a criação das novas interfaces com usuários, tradicionalmente páginas, em sistemas PHP, são as entidades que são então enviadas para a visão para que, a partir das informações destas entidades, venha a desenhar a página corretamente. A camada de Visão pode conter alguma complexidade que se faça necessária para a criação dos elementos de tela tais como menus, paginação, validações, etc. Guia_Arquitetura.doc 39

241 A camada de Visão pode se comunicar com a controladora obtendo assim mais informações que sejam necessárias para se desenhar a página de resultado. Nessas chamadas a Controladora pode chamar o Negócio que pode chamar a Persistência Template Os Templates não são tradicionalmente considerados uma camada da aplicação mas um conjunto de arquivos que vem a auxiliar a Visão na criação das páginas HTML. Os Templates são arquivos que lembram trechos de páginas HTML mas com trechos PHP para a criação dos conteúdos dinâmicos. Os Templates não devem ter a criação de novos métodos, funções ou classes. O código no template é exclusivamente para a saída de conteúdo HTML. Templates podem incluir outros Templates embora essa prática aplicada em muitos níveis costuma dificultar a manutenção do sistema. Uma visão também pode chamar vários Templates desde que o HTML resultante da operação de montagem seja um XHTML válido Segurança Guia_Arquitetura.doc 40

242 A Camada de Segurança é a camada responsável por avaliar se o usuário tem a permissão de acessar a funcionalidade desejada. Algumas implementações criam essa camada apenas como uma classe de Negócio mas é importante lembrar que a checagem da segurança deve ser feita antes de qualquer outra chamada de Negócio e que a controladora deve estar pronta para tratar caso o usuário esteja tentando fazer uma operação que não tenha permissão. Alguns controles de segurança extras podem e devem ser feitos dentro da camada de Negócio. Por exemplo, um usuário com o perfil professor pode ter a permissão de informar a nota dos seus alunos mas não deve poder informar a nota de alunos de outros professores. Deste modo, apesar do usuário ganhar a permissão de executar a operação Informar nota de Aluno pela camada de Segurança, a camada de negócio deve validar se a permissão também se aplica aquele caso, podendo também vir a gerar uma exceção por tentativa de operação a qual o usuário não tem a permissão de executar. Deixar a checagem de segurança para a entrada de cada método do Negócio gera um problema de permissões em cascata. Um usuário além de precisar da permissão de um método de Negocio, precisaria da permissão de todos os métodos de Negócio que fossem chamados. Esse tipo de problema é de difícil detecção, difícil reprodução e acaba jogando para o cliente o controle de uma arvore de dependencias que ele desconhece. A camada de segurança gera um mecanismo de controle de permissão simples, confiável e flexível. Casos especiais podem e devem ser tratados dentro da camada de Negócio Banco de Dados O Banco de Dados ou Sistema Gerenciador de Bancos de Dados é uma aplicação externa ao PHP que executa os comandos solicitados pela Persistência, salvando, alterando, removendo e buscando os registros em sua estrutura. Os comandos feitos pela persistência devem ser coerentes ao comando que o Banco de Dados é capaz de interpretar. Para facilitar tal comunicação, existem abstrações de Banco de Dados, extensões ou componentes que recebem comandos escritos no padrão SQL e convertem num comando compreensível ao Banco de Dados utilizado. As regras de boas práticas para Banco de Dados devem ser seguidas nos comandos enviados ao Banco de Dados, assim como o controle de segurança de acesso ao Banco de Dados. Uma prática recomendada é a utilização de diferentes usuários de Banco de Dados para escrita ou leitura. Além disso, algumas aplicações utilizam diferentes usuários de Banco de Dados para atividades de diferentes perfis de usuário da aplicação. Essa prática aumenta a complexidade do controle transacional mas reduz o risco e impacto de um ataque contra o sistema. Guia_Arquitetura.doc 41

243 2.9. Web Service A W3C define um "Web Service" como um sistema de software designado para suportar interações máquina-para-máquina com interoperabilidade numa rede. Também chamados de "Grandes Serviços Web", os Serviços Web trocam mensagens na Linguagem de Marcação Extensível (XML), através do padrão do Protocolo Simples de Acesso a Objetos (SOAP), padrão este que se estabeleceu no meio corporativo. Em tais sistemas, existe freqüentemente uma descrição das operações oferecidas pelo serviço, escrita na Linguagem de Descrição de Serviços Web ( WSDL). Esse documento não é necessário para a execução do serviço mas é para a geração automática do código cliente em diversas plataformas. Algumas organizações, tais como a WS-I definem como um Serviço Web a disponibilidade do serviço numa rede juntamente com o WSDL, necessariamente. O PHP apresenta nativamente alguns mecanismos que visam facilitar a utilização de Web Guia_Arquitetura.doc 42

244 Services nos projetos PHP, tanto para o desenvolvimento de clientes quanto de servidores. Para fazer uso de tais recursos recomendamos que as classes que forem funcionar como Servidores Web Services venham a utilizar alguma forma de abstração de criação de WSDL como WsdlDocument. Recomenda-se que os métodos dos Webs Services sejam atômicos, com poucas mensagens de erro por execução e que utilizem os mesmos métodos dos negócios dos utilizados pelas controladoras. 3. Componentes e Modularidade 3.1. Coesão e Acoplamento Em ciência da computação, acoplamento ou dependência é o nível o qual cada módulo do programa depende de outros módulos. O conceito de acoplamento é contrastado com a coesão. Quanto maior a coesão menor o acoplamento, e vice-versa. Coesão e Acoplamento foram temas muito discutidos por Larry Constantine e Edward Yourdon no famoso livro de 1976, Structured Design. Nesse livro, Larry Constantine inventou uma métrica para controle de qualidade de software baseada na coesão e no acoplamento. Esses conceitos foram inicialmente aplicados na programação estruturada e recentemente adaptados a programação orientada a objetos. Baixo acoplamento é freqüentemente um sinal de um software bem estruturado e de um bom design. Quando combinado com uma alta coesão, permite ao sistema uma alta legibilidade e alta manutenabilidade. Coesão é então uma medida de qualidade que pode ser extraída a partir de uma análise do código Modularidade Modularidade é o termo para o projeto de um sistema que é composto de várias partes que podem ser trocadas. Desta forma o sistema pode ser dividido em vários subsistemas (incluindo neste as diversas opções resultantes de trocas). Os sistemas podem ser processos ou produtos. Cada parte que pode ser trocada é um módulo. Componentes de Software é o termo utilizado para descrever o elemento de software que encapsula uma série de funcionalidades. Um componente é uma unidade independente, que pode ser utilizado com outros componentes para formar um sistema mais complexo. Em programação orientada a objetos um componente é o objeto que implementa uma interface e é Guia_Arquitetura.doc 43

245 autônomo em relação a outros componentes do sistema. Isso aumenta a modularidade do sistema como um todo na manutenção dos componentes Modularidade Componentes permitem que novas funcionalidades sejam adicionadas ao sistema de maneira coesa e reduzindo o acoplamento com o restante do projeto. Esse tipo de organização possibilita a modificação da implementação de um componente tenha o menor impacto possível no restante do projeto. Para fins de camada os componentes são elementos de negócio mas não são necessariamente estáticos e costumam possuir Entidades próprias do seu contexto. Alguns exemplos de componentes: Gerador de PDF; Gerador de Planilha Excel; Componente de Cache de Arquivos; Gerador de Log; Gerador de Estatísticas do Log; Gerador de Gráficos; Gerador de Caderno de Impressão; Gerador de Relatórios; Componente de Manipulação de Sessão; Gerador de Apresentação PPT; Gerador de Streaming de Vídeo; Componente para Redimensionar Imagem; Componente de Erro. Nessa analise, a camada de Segurança e a camada de Web Service podem ser vistos como componentes. Pois são objetos similares aos objetos de Negócio, que interagem com os objetos de Guia_Arquitetura.doc 44

246 Negócio, que podem ter suas Entidades próprias e que tem um propósito claro e definido gerando um código coeso com o resto do sistema sem gerar um aumento desnecessário no acoplamento. Os componentes podem ter uma dependência entre si. Além disso, alguns componentes interagem com alguns outros caso estejam disponíveis, mas não dependem da existência dos mesmos para funcionar adequadamente. O componente de Erro pode interagir com o componente de Log caso esse esteja disponível, mas pode continuar funcionando caso este não esteja instalado. O componente de Template pode utilizar o componente de Cache caso esse esteja disponível. Guia_Arquitetura.doc 45

247 Guia de Escrita de Caso de Uso Metodologia de Gestão do Desenvolvimento de Sistemas

248 Data Versão Descrição Autor 15/06/ Elaboração da proposta do Guia de Escrita de Caso de uso 21/06/ Finalização da proposta do Guia de Escrita de Caso de uso 23/06/ Ajustes após a revisão interna da equipe EP. Luciana Barros Luciana Barros Luciana Barros Metodologia de Gestão do Desenvolvimento de Sistemas

249 Metodologia de Gestão do Desenvolvimento de Sistemas

250 Este documento tem como propósito apresentar uma sugestão para a padronização de escrita para a especificação do caso de uso, visando a disciplinar as equipes de projeto, internas e externas, a usarem a mesma linguagem para facilitar e agilizar o processo do desenvolvimento. As definições a seguir são aderentes às melhores práticas de mercado e adequadas à Metodologia de Gestão e Desenvolvimento de Sistemas do INEP. Este documento está organizado com as definições dos itens e exemplos práticos para o template de caso de uso disponível como um artefato opcional da metodologia do órgão. A especificação de caso de uso descreve o comportamento do sistema sob diversas condições, de acordo com a requisição de um cliente, ou envolvido (stakeholders). Diferentes seqüências de comportamentos ou cenários podem surgir dependendo das requisições particulares solicitadas e das condições que cercam tais requisições, as quais devem ser escritas uma a uma. A especificação de caso de uso é fundamentalmente, uma forma textual, embora possa ser escrita usando fluxogramas ou português estruturado. Os casos de uso servem como meio de comunicação e representação das funcionalidades do sistema. Portanto, o texto simples é sempre a melhor escolha. Conforme previsto na metodologia do órgão, este artefato será utilizado de acordo com a definição da equipe técnica em conjunto com o gestor de forma a atender a necessidade do projeto quanto ao prazo, custo e recursos. 4.1 Breve descrição A descrição do caso de uso deve refletir sua finalidade e deve consistir de um texto que reflita a proposta central do caso de uso de forma clara e completa. A descrição do caso de uso deverá evidenciar se o caso de uso é Abstrato. Quando essa evidência não ocorrer o caso de uso será classificado como Concreto. Exemplo: Este caso de uso é uma extensão do caso de uso Pesquisar escola. Para cadastrar uma nova escola é necessário realizar uma pesquisa anterior garantindo assim um cadastro único para cada escola. O cadastro da escola nova contempla a inclusão e alteração dos dados de identificação da escola, geração do código INEP e código de desbloqueio da escola. 4.2 Atores Nesta seção deve ser abordada a definição e a responsabilidade de pessoas ou entidades envolvidas na realização das atividades descritas no documento. Exemplo: Metodologia de Gestão do Desenvolvimento de Sistemas

251 Usuário INEP é um ator do tipo humano que possui acesso às escolas de todas as redes dos municípios pertencentes a todos os estados brasileiros. Este ator necessita de acesso a Internet e deve ter perfil com permissão para cadastrar escola nova. Usuário Secretaria Estadual é um ator do tipo humano que possui acesso às escolas de todas as redes e municípios pertencentes ao estado a que está vinculado. Este ator necessita de acesso a Internet e deve ter perfil com permissão para cadastrar escola nova. 4.3 Pré-condições Uma pré-condição descreve o estado em que o sistema deve estar antes do caso de uso ser iniciado. Esse estado deve ser observável pelo usuário, porém não é o evento que inicia o caso de uso e pode ser considerado uma premissa. A informação em uma pré-condição somente deve ser incluída na especificação quando for aplicável. ATENÇÃO: Na situação em que uma pré-condição seja tratada em fluxo de exceção ou alternativo do mesmo, essa informação deverá deixar de ser registrada na seção de précondição. Exemplo: 1 - Não existir o cadastro da escola - Para que uma escola seja cadastrada como nova é preciso garantir que a escola não exista no banco de dados do sistema Educacenso. 4.4 Fluxo de eventos Esta seção é composta pelos fluxo principal, fluxo alternativo e fluxo de exceção, ou seja, todos os cenários devem ser contemplados nestes fluxos. O fluxo deverá definir claramente todos os seus possíveis pontos de entrada, bem como seu ponto de saída. No último passo do fluxo deve-se deixar claro que o caso de uso é finalizado. Cada passo deve ser terminado com ponto e vírgula e no último passo deve-se colocar o ponto final. ATENÇÃO: Os passos do fluxo que referenciam os fluxos de exceção e os alternativos são excludentes entre si. Ou seja, no passo em que houver a referência FA e FE, ou o sistema executa o decrito no passo que contém a referência OU executa o FA ou FE. Por isso, não deve ser usado os termos condicionais: caso, se e quando nos passos. Um caso de uso pode ser abstrato ou concreto. O caso de uso concreto é iniciado por um ator e constitui fluxo completo de eventos. "Completo" significa que uma instância do caso de uso executa a operação inteira chamada pelo ator. O caso de uso abstrato propriamente nunca é instanciado. Os casos de uso abstratos são incluídos em, se estendem para, ou generalizam outros casos de uso. A distinção entre os dois é importante porque são os casos de uso concretos que os atores "verão" e iniciarão no sistema. 4.5 Fluxo Principal O fluxo principal é o caminho feliz da funcionalidade, ou seja, os passos consistentes para atingir o objetivo do caso de uso. Deste fluxo saem os fluxos alternativos e os de tratamento de erros, os fluxos de exceção. É importante conter um título que o identifique claramente e a seqüência ser numerada para os passos. Para referenciar um ponto de saída ou entrada, deve ser usado o termo PASSO e não item do fluxo referido. Exemplo: Metodologia de Gestão do Desenvolvimento de Sistemas

252 Este fluxo tem início quando o sistema identifica que o ator selecionou a opção cadastrar escola nova. P1 - O sistema apresenta para preenchimento as seguintes informações de identificação da escola: Situação de funcionamento. Ano letivo: início Ano letivo: Término (previsão) Nome da escola CEP [RN04] Endereço Número Complemento Bairro UF Município Distrito DDD Telefone Telefone público (1) Telefone público (2) Fax Endereço eletrônico ( ) Código do Órgão Regional de Ensino Nome do Órgão Regional de Ensino Dependência administrativa (Federal, Estadual,Municipal e Privada) Localização/ Zona da escola (Urbana e rural) CNPJ da Unidade executora (pública ou privada filantrópica) Categoria da escola privada (Particular, comunitária, confessional e filantrópica) Conveniada com o poder público (Estadual, municipal) Número do registro no CNAS Número de certificado de entidade beneficente de assistência social - CEBAS Mantenedora da escola privada Número do CNPJ da escola privada Regulamentação /Credenciamento no conselho ou órgão municipal, estadual ou federal de educação (Sim, em tramitação e não) Dados para Autenticação: Nome do diretor/ responsável CPF do diretor / responsável Cargo do diretor / responsável Endereço eletrônico do diretor / responsável P2 - O ator preenche as informações para o cadastro da escola. P3 - O ator seleciona a opção que permite salvar as informações. (E1); (E2); P4 - O sistema valida as informações inseridas e verifica se todos os dados do cadastro da escola são válidos conforme as regras [RN01], [RN02] e [RN03]. P5 - O sistema apresenta as seguintes informações para visualização: Mensagem informando que a escola foi cadastrada com sucesso conforme MSG012. O código da entidade no INEP O código de desbloqueio. P6 - O caso de uso é encerrado. 4.6 Fluxo Alternativo O fluxo alternativo é aquele que o sistema identifica que o ator adotou outro caminho, opcionalmente, diferente do caminho feliz. São aquelas situações em que exista desvio do caminho definido pelo fluxo principal; nestas ocasiões, devem-se utilizar a abordagem de fluxo alternativo. Metodologia de Gestão do Desenvolvimento de Sistemas

253 Cada fluxo alternativo deverá conter um título que o descreva de forma correta e clara. Para esses fluxos opcionais ou alternativos recomenda-se descrever cada subfluxo em um suplemento separado da seção do comportamento normal. Esse procedimento é obrigatório nos seguintes casos: Subfluxos que ocupam um grande segmento de um determinado fluxo principal. Qualquer subfluxo que possa ser executado em vários intervalos do mesmo fluxo de eventos. Exemplo: Não se aplica. (neste exemplo de caso de uso) Estrutura: FAn - <nome do fluxo> No passo X.x do fluxo a, o sistema verifica/ identifica que... An.1 - O ator... An.2 - O caso de uso retorna ao passo X.1 do fluxo a. 4.7 Fluxo de Exceção Abrangem as situações de eventos incomuns ou excepcionais. As exceções são subfluxos do caso de uso que não é compatível com o comportamento normal (fluxo principal); nestes casos, deve-se utilizar a abordagem de fluxo de exceção. Cada fluxo de exceção deverá conter um título que o descreva claramente. Um fluxo de exceção descreve os tratamentos das exceções surgidas nos fluxos principal e alternativo, que resultem na interrupção do cenário de sucesso esperado. Os eventos de exceção estão relacionados com a violação de regras de negócio e regras de integridade do sistema. Possíveis situações: Preenchimento inválido de valores, validação de regras de preenchimento, comparação de campos; impossibilidade de exclusão de registros por estarem referenciados em outras entidades. Exemplo: E1 - Data inválida No passo P3 do fluxo principal, o sistema identifica que foi informada uma data inválida conforme o calendário anual nacional. E1.1 - O sistema exibe a mensagem MSG03 para informar que a data é inválida. E1.2 - O caso de uso retorna ao passo P2 do fluxo principal. E2 - Campos obrigatórios não informados No passo P3 do fluxo principal, o sistema identifica que pelo menos um campo obrigatório não foi informado. E2.1 - O sistema exibe a mensagem MSG04 para informar que o campo deve ser informado. E2.2 - O caso de uso retorna ao passo P2 do fluxo principal. 4.8 Pós-condições Uma ou mais pós-condição descrevem os possíveis estados que o sistema deve estar após a finalização do caso de uso. Ao fazer uso deste recurso em casos de uso que possuem pontos de extensão, é preciso garantir que os passos definidos no caso de uso de extensão não violem a pós-condição definida. Este tipo de informação somente deve ser incluído na Metodologia de Gestão do Desenvolvimento de Sistemas

254 especificação, quando aplicável. Caso não exista pós-condição, sugere-se utilizar: Não se aplica. OBS.: A pós-condição deve ser relevante e não o objetivo do caso de uso. As pós-condições são usadas para reduzir a complexidade e melhorar a compreensão do fluxo de eventos do caso de uso. 4.9 Pontos de extensão Sendo um caso de uso base, indicar a existência do relacionamento de extensão nesta seção, do documento. Descrever a ação de um caso de uso chamar outro caso de uso. O ponto de extensão (PE) deve se comportar como um fluxo alternativo, ou seja, o caso de uso base (chamador) deve ser completo em si mesmo, o que significa que deve ser compreensível e fazer sentido sem nenhuma referência a extensões. Exemplo: Não se aplica. Estrutura: PEx Nome do caso de uso de extensão <Breve descrição apresentando também o ponto onde o ponto de extensão é chamado no caso de uso> 4.10 Requisitos Especiais Nesta seção devem ser descritas as informações pertinentes aos requisitos de negócios deste caso de uso. Ou seja, aqueles requisitos que não são abordados pelo fluxo de eventos. Esses requisitos provavelmente serão Não-funcionais e influenciarão o modelo do design. Pode ser organizado em categorias como: usabilidade, confiabilidade e desempenho, mas geralmente são tão poucos que esses agrupamentos não são particularmente úteis. Exemplo: O tempo de efetivação do cadastro da escola nova deve ser de 2 segundos e disponibilizado automaticamente na base de dados para consulta e alteração das informações Regras Nesta seção devem ser descritas todas as informações pertinentes aos componentes de tela, bem como as regras de negócio específicas deste caso de uso. As demais regras que não se enquadarem nas tabelas devem ser descritas em forma de textual e numeradas seguindo os exemplos nas tabelas. Exemplos: RN01 - Informações gerais NOME DO CAMPO TIPO TAMANHO/ MÁSCARA DESCRIÇÃO DETALHAMENTO HINT <nome do componente na tela conforme wireframe ou protótipo, campos, ícones, links devem refletir exatamente a forma descrita na tela de referência> <nome do tipo do componente (conforme lista de tipos possíveis no leiaute)> <definição clara para o componente> <informar detalhes como por exemplo: ordenação,valores do domínio, valor padrão, dependência entre componentes da tela > <texto significativo que aparecerá no hint, verificar o limite do tamanho> Metodologia de Gestão do Desenvolvimento de Sistemas

255 NOME DO CAMPO TIPO TAMANHO/ MÁSCARA DESCRIÇÃO DETALHAMENTO HINT Nome da escola Texto/ 100 caracteres. Nome completo da escola que seja único e claro para identificação da mesma. Informação obrigatória para a realização do cadastro. N.A. Situação de funcionamento Lista/ 20 caracteres Situação do funcionamento da escola conforme descrito na regra RN03 Valores possíveis conforme RN02. Apresentar os valores em ordem alfabética. Não há valor default é obrigatório que o ator selecione pelo menos um. N.A. Comentário: Com referencia cruzada para o item. Facilitando assim o acesso do desenvolvedor. Ano letivo início Data Data início do período do ano letivo. Ano letivo término Data Data fim do período do ano letivo.... Continuação das outras informações de tela. Informação obrigatória. Validar a data conforme calendário nacional. Informação obrigatória. Validar a data conforme calendário nacional. A data fim do ano letivo deve ser maior que a data do início, N.A. N.A. RN02 - Nome da escola O nome do estabelecimento de ensino é uma informação obrigatória. O preenchimento deve respeitar as seguintes definições: o Aceitar os seguintes caracteres: Alfa (A-Z), numérico (0-9), especiais ( ª º - ); o Ter no mínimo 4 dígitos. RN03 - Situação de funcionamento A situação de funcionamento da escola é uma informação obrigatória. Deve ser selecionado um dos seguintes valores válidos: 1 Em Atividade: Escola em Funcionamento; 2 Paralisada: Escola com as atividades temporariamente suspensas. Se esta situação for informada os seguintes campos não estarão disponíveis para edição: o Ano letivo: início o Ano letivo: Término (previsão) o CNPJ da Unidade executora (pública ou privada filantrópica) o Categoria da escola privada o Conveniada com o poder público o Número do registro no CNAS o Número de certificado de entidade beneficente de assistência social - CEBAS o Mantenedora da escola privada o Número do CNPJ da escola privada o Regulamentação /Credenciamento no conselho ou órgão municipal, estadual ou federal de educação. RN04 - Período letivo (Início do ano letivo e Fim do ano letivo) O período letivo compreende a data de início do ano letivo e data prevista do fim do ano letivo: Metodologia de Gestão do Desenvolvimento de Sistemas

256 Início do ano letivo - Obrigatório para as escolas que preencheram a situação de funcionamento como "Em Atividade" (campo 1). O ano da data de início não pode ser superior ao ano da data de término e não pode ser inferior a 2009 ou superior a 2010, ou seja, deve estar compreendido no seguinte intervalo: 02/01/ /12/2010. Fim do ano letivo Previsão do final do ano letivo da escola. Obrigatório para as escolas que preencheram a situação de funcionamento como "Em Atividade" (campo 1). O ano da data de término não pode ser inferior a data de início ou superior a 2011, ou seja, deve estar compreendido no seguinte intervalo: Data de início < Data de término 31/12/2011. RN05 - CEP da escola Código de Endereçamento Postal da escola é uma informação obrigatória e deve ser informado de acordo com a tabela de Municípios e possuir 8 caracteres numéricos Assinaturas Esta seção deve conter a(s) assinatura(s) do(s) gestor(es) responsável(is) pela homologação/ validação, os quais estão definidos no documento de visão do projeto, bem como, a(s) assinatura(s) do(s) responsável(is) pela equipe do projeto. Os abaixo assinados estão de acordo com o conteúdo deste documento. <nome do gestor> Carimbo <nome do GP equipe projeto INEP> <matrícula> Metodologia de Gestão do Desenvolvimento de Sistemas

257 Cada passo de um fluxo deve descrever uma interação completa do ator ou do sistema: o Usar: 2. O ator informa dados do funcionário e aciona a opção para Inserir. o NÃO usar: 3. O ator informa dados do funcionário 4. O ator aciona a opção para Inserir. Usar voz ativa: o Usar: O ator informa dados do funcionário. o NÃO usar: Os dados de funcionário são informados pelo ator Generalizar o nome do ator ao descrever o passo, não utilizar o nome da função que ele ocupa no processo, por exemplo: o Usar: O ator informa dados do funcionário. o NÃO usar: O Gerente informa dados do funcionário. Não usar termos técnicos ou que se refiram à interface: o Usar: Solicita, lista, seleciona, inicia, especifica, envia, escolhe, exibe, apresenta, informa. o NÃO usar: Arrasta, formulário, fecha, abre, clica, drop-down, botão, combobox, pop-up, barra de rolagem, browse, janela, tela. Não usar termos que se refiram à arquitetura ou a forma de implementação, o foco deve sempre estar no comportamento. Como definir comportamentos repetitivos? Exemplo: O ator pode adicionar e remover disciplinas para o aluno até selecionar a opção de Salvar. Na descrição dos passos usar sempre verbos no presente. Quando devemos usar casos de uso de extensão (extend)? Recomenda-se que, sempre que possível, se evite os relacionamentos de extensão. Como regra geral, deve-se dar preferência a atualizar a seção "Fluxos alternativos", em vez de criar relacionamentos complexos entre casos de uso. Ou seja, é preferível adicionar um cenário extra na seção "Fluxos alternativos" a criar casos de uso separados. Estes deverão ser criados quando for um comportamento complexo e utilizado por mais de um caso de uso para que valha a pena o tipo de relacionamento. Na especificação do caso de uso de extensão (o estendido) é sugerido para descrição inicial do fluxo de evento: "Este caso de uso é uma extensão do(s) caso(s) de uso [nome do(s) caso(s) de uso]. Quando for iniciado pelo ator ou como extensão de outro caso de uso: Este caso de uso inicia quando [descrever a condição que inicia do caso de uso] ou quando é uma extensão do(s) caso(s) de uso [nome do(s) caso(s) de uso]. Quando for Include - Na especificação do caso de uso base, para indicar a existência do relacionamento de inclusão na estrutura dos fluxos de eventos do caso de uso é sugerido utilizar o indicativo no passo que ocorre, por exemplo: P2 O sistema exibe as informações dos cursos que o aluno está associado incluir caso de uso Apresentar Cursos. Não é necessário informar os parâmetros de entrada e saída para um caso de uso incluído. Na especificação do caso de uso de inclusão (o incluído), listar na seção de Atores, todos os atores envolvidos no(s) caso(s) de uso base (aquele que o chama). É sugerido utilizar no texto "Este caso de uso é uma inclusão do(s) caso(s) de uso [nome do(s) caso(s) de uso]. Metodologia de Gestão do Desenvolvimento de Sistemas

258 Padronizar a ordenação das referências em todas as especificações para facilitar o entendimento e desenvolvimento do implementador. Sugestão: regras de negócios de caso de uso [RNxx], fluxos alternativos (FAxx), fluxos de exceção(fexx) e pontos de extensão(pexx). Utilizar o artifício de referência cruzada do editor de texto sugere-se incluir somente o número do parágrafo para as referências colocadas ao final do passo correspondente. Nível de detalhamento (abstração) dos fluxos o caso de uso é descrito na visão do usuário, de forma simples, completa e clara. Para isso, é necessário utilizar uma linguagem adequada para o entendimento comum entre equipe técnica e usuário. Concentre-se na descrição do que é feito no caso de uso, e não em como problemas específicos e internos do sistema devem ser solucionados, os modelos de objetos existem para esta finalidade. Descreva apenas os fluxos que pertencem ao caso de uso, e não o que ocorre em outros casos de uso utilizados paralelamente a esse. Jamais repetir fluxos que ocorrem em outro caso de uso. Não mencione os atores que não se comunicam com o caso de uso em questão. Não insira excesso de detalhes ao descrever a interação do caso de uso com os atores. As informações, dados trocados entre ator e sistema devem ser explícitos. Use os termos do glossário comum e considere as seguintes questões ao redigir o texto: Use vocabulário claro e direto. Não use termos complexos quando um termo simples pode ser usado. Crie frases curtas e concisas. Evite advérbios, como muito, mais, bastante e outros semelhantes. Use a pontuação correta. Evite frases compostas. Metodologia de Gestão do Desenvolvimento de Sistemas

259 Guia de Contagem de Pontos de Função Versão 6.2 janeiro/2010

260 Sumário 1 INTRODUÇÃO FATOR DE AJUSTE TIPOS DE DEMANDA Iniciação...4 Desenvolvimento...4 Manutenção...7 MEDIÇÃO DAS MANUTENÇÕES Dicas para otimizar o custo das manutenções Campos Não Editáveis (Read-Only) Subdivisão de uma Funcionalidade em n Funções Impressão de Termos e Formulários Envio de Identificação de Tipos de Registro e Arquivos Lógicos Conversão de Dados Middleware Processos Sem Interface Gráfica (batch) Data Warehouse e BI Workflow Views/Visões em Bancos de Dados Transações compartilhadas entre várias aplicações Consultas com múltiplas mídias Funções transacionais acessadas por diversos perfis de usuário Consultas/Pesquisas com diversas opções de filtro Critérios de ordenação e agrupamento Histórico Trilha de Auditoria Integração com o sistema de segurança do INEP PRODUTIVIDADE BÁSICA E TIPOS DE CONTAGEM ITENS NÃO MENSURÁVEIS PELA ANÁLISE DE PONTOS DE FUNÇÃO Manutenção Adaptativa Manutenção Corretiva Manutenção Cosmética Dados de Código Mensagens Parâmetros de Processamento Forma de Ordenação Tabelas não mantidas pelo Usuário Programas Auxiliares Páginas Estáticas Tabela de Itens Não Mensuráveis (INMs) MEDIÇÃO DE PROJETOS/SERVIÇOS CANCELADOS REFERÊNCIAS Guia de Contagem de Pontos de Função 2/39

261 Histórico de Revisões Data Versão Descrição Autor 06/ Grupo de Métricas do COMINF 3 Elaboração da proposta do Guia de Contagem. Alterações após apresentação para o COMINF Adaptação do guia para a realidade do Inep 07/ / / Revisão 06/ / / / / / Revisão na sessão Definições e Premissas Alteração no processo de medição para adequar a nova estrutura da DTDIE, reestruturação do escritório de projetos e criação do núcleo de métricas. Reestruturação do documento: Exclusão das definições que constam no guia CPM; Exclusão o assunto Bônus, por não fazer sentido no fluxo da MGDS; Reescrita do texto, acomodando-o nas seções seções Tipos de Demanda, Categorias de Manutenção, Produtividade Básica e Tipos de Contagem ; Transferência da seção Alteração de Escopo para a MGDS; Reestruturação da seção Itens Não Mensuráveis. Substituição do item Categorias de Manutenção (Item 4) por Medição das Manutenções e acréscimo dos itens 4.1 a Remoção do item 6 (Aplicação da técnica para casos específicos), com seu conteúdo remanejado para o item 4, no que se aplicou (itens 4.17 a 4.20). Inclusão dos exemplos nos itens 3.2 e 3.3 Complementação dos itens 3.2 e 3.3. Guia de Contagem de Pontos de Função Grupo de Métricas do COMINF Daniel Mundim Ribeiro Diogo de A. Rodrigues Medeiros Fábio Divino da Silva Joao Paulo Militão de Alencar José Jesse Gonçalves Ladjane Silva Arruda Roberto da Silva Nunes Rodrigo Pereira de Mesquita Rosa Maria da Costa Medeiros Sandro Alex Damasceno Costa Thiago Fagury de Sá Rosa Maria Medeiros Rosa Maria Medeiros Luciana Gonçalves Chaves Barros Luciana Gonçalves Chaves Barros Rosa Maria da Costa Medeiros Rosa Maria da Costa Medeiros Rosa Maria da Costa Medeiros Rosa Maria da Costa Medeiros 3/39

262 1 Introdução Este documento foi construído para facilitar o uso da técnica de pontos de função dentro do contexto de desenvolvimento e manutenção de sistemas do Inep, funcionando como um complemento ao Manual de Práticas de Contagem do IFPUG, versão 4.2.1, que estabelece o padrão para contagem de pontos de função. Este guia apresenta cenários de situações peculiares ao Inep e fornece orientação para aplicação em situações não previstas no Manual de Práticas de Contagem do IFPUG. Quaisquer sugestões de modificações para este documento deverão ser submetidas ao Núcleo de Métricas do INEP, que analisará a pertinência da inclusão, no presente documento, dos itens sugeridos. 2 Fator de ajuste O fator que indica a funcionalidade geral fornecida ao usuário da aplicação. O VAF é calculado baseado na avaliação das 14 características gerais do sistema (CGSs) para uma aplicação. Para as contagens de pontos de função disciplinadas por este documento, o fator de ajuste será fixado no valor 1,0 (um) para não afetar o tamanho obtido dos pontos de função não-ajustados assim seus valores ficam sempre iguais aos pontos de função ajustados. 3 Tipos de Demanda 3.1 Iniciação Durante a fase de iniciação de um projeto, o Gerente de Projetos responsável pelo atendimento a uma determinada área de negócio decide quem deverá realizar as atividades de construção da Visão do produto junto ao Cliente: se sua equipe interna ou se a empresa fornecedora. Caso o Gerente de Projetos decida que a Visão do Produto será construída pela empresa fornecedora, será aberta uma Ordem de Serviço de Iniciação. Depois de construir e validar a Visão do Produto junto ao Cliente, a empresa fornecedora aplicará a técnica de contagem estimativa da NESMA para obter o tamanho estimado da demanda. Após a validação e o aceite da contagem, o Gerente de Projetos do Inep calculará 5% do total estimado de pontos de função e os registrará na respectiva Ordem de Serviço de Iniciação, encaminhando-a para pagamento. 3.2 Desenvolvimento Uma demanda de desenvolvimento é caracterizada pela necessidade de construção de um novo sistema. No Inep, os projetos de desenvolvimento são divididos em entregas (releases), compostas por uma ou mais iterações (sprints). Para cada iteração é realizada uma contagem estimativa que irá subsidiar a abertura de uma Ordem de Serviço. A alteração de requisitos é natural em projetos de desenvolvimento de sistemas. À medida que o tempo passa, os envolvidos vão ganhando maior conhecimento da necessidade que originou a demanda de um novo sistema, e essas mudanças devem ser acomodadas naturalmente dentro do processo. A isso se dá o nome de "evolução de requisitos", também conhecida por "scope creep". Guia de Contagem de Pontos de Função 4/39

263 No Inep, mudanças de requisitos em uma sprint são, na medida do possível, acomodadas no backlog do produto, para execução em iteração posterior. Em um projeto de desenvolvimento, as alterações nos requisitos serão cobertas por um conjunto de redutores, que serão aplicados sobre as funções já construídas em iterações anteriores e que foram alteradas ou excluídas em determinada iteração, conforme a tabela a seguir: Tipo de Ação Redutor Significado Funções incluídas (novas) 1,0 O Inep pagará 100% do tamanho funcional dos pontos de função incluídos. Funções alteradas 0,6 O Inep pagará 60% do tamanho funcional dos pontos de função alterados. Funções excluídas 0,25 O Inep pagará 25% do tamanho funcional dos pontos de função excluídos. Em um projeto de desenvolvimento, a cada sprint finalizada, será realizada uma contagem detalhada sobre os itens executados na iteração atual (com a aplicação dos redutores acima citados onde forem aplicáveis), para apuração da quantidade de pontos de função efetivamente entregues por essa sprint. Após a validação e o aceite dos pontos de função, o Gerente de Projetos do Inep registrará essa quantidade na Ordem de Serviço da sprint atual, encaminhando-a para pagamento. Exemplo de um projeto de desenvolvimento Considerando o backlog de um projeto de desenvolvimento de um novo sistema, distribuído em 3 sprints: Cadastrar Ordem de Serviço; Consultar Ordem de Serviço; Alterar Ordem de Serviço; Cancelar Ordem de Serviço; Relatório da Ordem de Serviço para impressão. Sprint 1: Inclusão da estória de usuário Cadastrar Ordem de Serviço. Inclusão da estória de usuário Consultar Ordem de Serviço. Contagem Detalhada da Sprint 1 Tipo Nome da Função Complex. PF Operação Redutor PF Local ALI Ordem de Serviço Baixa 7 Inclusão 1 7 EE Cadastrar OS Baixa 3 Inclusão 1 3 CE Consultar OS Baixa 3 Inclusão 1 3 Tamanho da Sprint 1 Guia de Contagem de Pontos de Função 13 5/39

264 Sprint 2: Alteração da estória de usuário Cadastrar Ordem de Serviço. Inclusão da estória de usuário Alterar Ordem de Serviço. Contagem Detalhada da Sprint 2 Tipo Nome da Função Complex. PF Operação Redutor PF Local ALI Ordem de Serviço Média 10 Alteração 0,6 6 EE Cadastrar OS Alta 6 Alteração 0,6 3,6 EE Alterar OS Alta 6 Inclusão 1 6 Tamanho da Sprint 2 15,6 Sprint 3: Alteração da estória de usuário Consultar Ordem de Serviço (não mudou a complexidade). Inclusão da estória de usuário Cancelar Ordem de Serviço. Inclusão da estória Relatório da Ordem de Serviço para Impressão. Contagem Detalhada da Sprint 3 Tipo Nome da Função Complex. PF Operação Redutor PF Local CE Consultar OS Baixa 3 Alteração 0,6 1,8 EE Cancelar OS Baixa 3 Inclusão 1 3 CE Relatório da OS Média 4 Inclusão 1 4 Tamanho da Sprint 3 8,8 Ao término do projeto de desenvolvimento, teremos a seguinte linha de base de pontos de função: Tipo Nome da Função Complexidade PF ALI Ordem de Serviço Média 10 EE Cadastrar OS Alta 6 CE Consultar OS Baixa 3 EE Alterar OS Alta 6 EE Cancelar OS Baixa 3 CE Relatório da OS Média 4 Total de pontos de função do desenvolvimento Guia de Contagem de Pontos de Função 32 PFs 6/39

265 Ao término do projeto, os PFs relativos ao tamanho total do projeto (com as mudanças) terão sido pagos da seguinte forma: OS da Sprint 1 13 PFs OS da Sprint 2 15,6 PFs OS da Sprint 3 8,8 PFs TOTAL 37,4 PFs Fim do exemplo de um projeto de desenvolvimento 3.3 Manutenção Uma demanda de manutenção é caracterizada pela necessidade de melhoria ou evolução de um sistema que esteja em produção. Essa evolução/melhoria pode ser implementada pelo acréscimo de funcionalidades novas ou pela alteração/exclusão de funcionalidades existentes. No Inep, a manutenção é abordada de duas formas: serviços de manutenção, para demandas de até 100 pontos de função; ou projetos de manutenção, para demandas de tamanho superior a 100 pontos de função. Os projetos de manutenção são divididos em entregas (releases), compostas por uma ou mais iterações (sprints). Para cada iteração é realizada uma contagem estimativa que irá subsidiar a abertura de uma Ordem de Serviço. Já os serviços de manutenção podem ser executados em uma ou mais iterações, a critério do Gerente de Projetos do Inep responsável pelo atendimento à área de negócio cliente. Porém, para cada iteração corresponderá sempre uma contagem estimativa e uma Ordem de Serviço. Demandas de Manutenção serão cobertas por um conjunto de redutores, que serão aplicados sobre as funcionalidades que já estavam em produção e foram alteradas ou excluídas, conforme tabela a seguir: Tipo de Ação Redutor Significado Funções incluídas (novas) 1,0 O Inep pagará 100% do tamanho funcional dos pontos de função incluídos. Funções alteradas 0,6 O Inep pagará 60% do tamanho funcional dos pontos de função alterados. Funções excluídas 0,25 O Inep pagará 25% do tamanho funcional dos pontos de função excluídos. Em uma demanda de manutenção, a cada sprint finalizada, será realizada uma contagem detalhada sobre os itens executados na iteração atual (com a aplicação dos redutores acima citados onde forem aplicáveis), para apuração da quantidade de pontos de função efetivamente entregues por essa sprint. Após a validação e o aceite dos pontos de função, o Gerente de Projetos do Inep registrará essa quantidade na Ordem de Serviço da sprint atual, encaminhando-a para pagamento. Guia de Contagem de Pontos de Função 7/39

266 Exemplo de um projeto de manutenção Considerando o mesmo backlog do exemplo anterior, distribuído em 3 sprints mas convertido em uma demanda de manutenção de um sistema existente: Cadastrar Ordem de Serviço; Consultar Ordem de Serviço; Alterar Ordem de Serviço; Cancelar Ordem de Serviço; Relatório da Ordem de Serviço para impressão. Sprint 1: Inclusão da estória de usuário Cadastrar Ordem de Serviço. Inclusão da estória de usuário Consultar Ordem de Serviço. Inclusão da estória de usuário Cancelar Ordem de Serviço. Contagem Detalhada da Sprint 1 Tipo Nome da Função Complex. PF Operação Redutor PF Local ALI Ordem de Serviço Baixa 7 Inclusão 1 7 EE Cadastrar OS Baixa 3 Inclusão 1 3 CE Consultar OS Baixa 3 Inclusão 1 3 EE Cancelar OS Baixa 3 Inclusão 1 3 Tamanho da Sprint 1 16 PFs Sprint 2: Alteração da estória de usuário Cadastrar Ordem de Serviço. Inclusão da estória de usuário Alterar Ordem de Serviço. Contagem Detalhada da Sprint 2 Tipo Nome da Função Complex. PF Operação Redutor PF Local ALI Ordem de Serviço Média 10 Alteração 0,6 6 EE Cadastrar OS Alta 6 Alteração 0,6 3,6 EE Alterar OS Alta 6 Inclusão 1 6 Tamanho da Sprint 2 15,6 PFs Sprint 3: Alteração da estória de usuário Consultar Ordem de Serviço (não mudou a complexidade). Exclusão da estória de usuário Cancelar Ordem de Serviço. Inclusão da estória Relatório da Ordem de Serviço para Impressão. Guia de Contagem de Pontos de Função 8/39

267 Contagem Detalhada da Sprint 3 Tipo Nome da Função Complex. PF Operação Redutor PF Local CE Consultar OS Baixa 3 Alteração 0,6 1,8 EE Cancelar OS Baixa 3 Exclusão 0,25 0,75 CE Relatório da OS Média 4 Inclusão 1 4 Tamanho da Sprint 2 6,55 PFs Ao término da demanda de manutenção, teremos a seguinte linha de base de pontos de função: Tipo Nome da Função Complexidade PF ALI Ordem de Serviço Média 10 EE Cadastrar OS Alta 6 CE Consultar OS Baixa 3 EE Alterar OS Alta 6 CE Relatório da OS Média 4 Total de pontos de função do desenvolvimento 29 PFs Ao término do serviço, os PFs relativos ao tamanho total da demanda terão sido pagos da seguinte forma: OS da Sprint 1 16 PFs OS da Sprint 2 15,6 PFs OS da Sprint 3 6,55 PFs TOTAL 38,15 PFs Fim do Exemplo de um projeto de manutenção Guia de Contagem de Pontos de Função 9/39

268 4 Medição das Manutenções A APF mede apenas os tipos de manutenção que alteram os requisitos de negócio (funcionais) de um software. O IFPUG adota a classificação das manutenções do IEEE (Institute of Electrical and Electronics Engineers), conforme segue: Manutenção Adaptativa para fazer com que o software continue sendo utilizável em um ambiente alterado. Manutenção Perfectiva para melhorar a performance, facilidade de manutenção ou outros atributos do software instalado. Manutenção Corretiva para corrigir falhas no hardware ou software. Para o IFPUG, a manutenção adaptativa atinge apenas requisitos funcionais, sendo então sinônimo de melhoria. Este tipo de manutenção é o único mensurável em pontos de função. De acordo com o IFPUG, a manutenção perfectiva abrange modificações em requisitos não funcionais. Por não haver requisitos de negócio/funcionais envolvidos, esse tipo de manutenção não pode ser medida em pontos de função. Porém, no ambiente do Inep, as manutenções são classificadas de forma diferente daquela adotada pelo IFPUG, conforme ilustrado pela tabela comparativa a seguir: IFPUG Inep Significado Adaptativa Evolutiva Alteração de requisitos funcionais. Perfectiva Adaptativa Alteração de requisitos não funcionais. Manutenção Evolutiva a manutenção evolutiva é caracterizada pela inclusão de modificações para satisfazer tanto requisitos novos como de mudança ou para incluir funcionalidades não fornecidas numa versão anterior. Também pode incluir modificações solicitadas para satisfazer requisitos técnicos de mudança. A manutenção evolutiva, no contexto do Inep, é iniciada pela solicitação do negócio para incluir, alterar e/ou excluir funcionalidades de negócio. É o equivalente ao conceito de "melhoria", como definido pelo IFPUG. Manutenção Adaptativa a manutenção adaptativa será tratada como Item Não Mensurável (INM), em seção detalhada mais adiante neste documento. Manutenção Corretiva na seção Itens Não Mensuráveis, detalhada mais adiante neste documento, encontra-se a abordagem a ser adotada pelo Inep para a gestão de demandas dessa natureza. No caso das manutenções mensuráveis, a técnica medirá sempre a funcionalidade completa, da forma como será entregue ao usuário, independente da extensão da manutenção. Ou seja, mede-se a função que foi alterada e não o quanto ela foi alterada. Portanto, conclui-se que a granularidade com que a APF mede a manutenção não é muito fina, mas isto não chega a ser um problema. Medir a extensão da manutenção (como é o caso da abordagem da NESMA) seria um refinamento maior da medição, porém tornaria o processo um pouco mais trabalhoso. Pela maneira como o IFPUG definiu a medição da manutenção em uma função (medir a função toda, como esta será entregue), faz com que, em vários casos, alterações muito pequenas na função tenham o mesmo tamanho de uma manutenção extensa na mesma função. Portanto para que não haja desperdício de recursos, é fundamental que se discipline uma maneira mais racional na demanda por manutenções (tratado a seguir). Guia de Contagem de Pontos de Função 10/39

269 Quando se está em um contexto em que diversas manutenções serão atendidas ao longo do tempo, o esforço ou custo derivado da medição pela APF para uma manutenção específica pode ser super ou subdimensionado. Mas ao analisar o conjunto das diversas manutenções em um horizonte de tempo maior (ao menos um ano), estas distorções tendem a se compensar se o parâmetro de preço (R$/PF) ou taxa de entrega (H/PF) foi bem estabelecido. 4.1 Dicas para otimizar o custo das manutenções É fundamental que se tenha uma atenção especial na gestão às demandas de manutenção de seus sistemas. Se toda demanda de manutenção que chegar for encaminhada diretamente para execução pelo fornecedor, a tendência é que o custo dessas manutenções ao final seja superior ao que poderia ser, caso houvesse um controle sobre essas solicitações. A seguir, algumas dicas podem ajudar a melhorar este cenário: a) Consolidar manutenções na mesma função em uma única demanda é a maneira mais fácil de racionalizar o custo. Já que o IFPUG não mede a extensão da manutenção na função afetada, fazer uma manutenção para atender a um único requisito ou para atender a vários requisitos de manutenção na mesma função terá o mesmo tamanho funcional, se elas forem solicitadas para o fornecedor no mesmo momento. Se solicitadas em momentos distintos, as mesmas funções serão pagas várias vezes, para cada um dos Projetos de Melhoria. Tomando como base o exemplo disponível no item 3.3, teríamos a seguinte lista de solicitações de manutenções a serem realizadas em determinado sistema, solicitações essas recebidas em momentos distintos: Inclusão da estória de usuário Cadastrar Ordem de Serviço. Inclusão da estória de usuário Consultar Ordem de Serviço. Inclusão da estória de usuário Cancelar Ordem de Serviço. Alteração da estória de usuário Cadastrar Ordem de Serviço. Inclusão da estória de usuário Alterar Ordem de Serviço. Alteração da estória de usuário Consultar Ordem de Serviço. Exclusão da estória de usuário Cancelar Ordem de Serviço. Inclusão da estória Relatório da Ordem de Serviço para Impressão. No exemplo do item 3.3, essas manutenções foram realizadas também em momentos distintos (3 sprints). Como visto na lista acima, a mesma funcionalidade apareceria mais de uma vez e, por conseqüência, seria paga mais de uma vez. No entanto, nem sempre é possível represar uma necessidade do usuário para que esta seja agrupada com outras, já que há demandas com prazos críticos. O importante é tentar avaliar ao máximo quais ajustes realmente são críticos e quais não são, visando evitar o cenário descrito acima. b) Reutilizar funções existentes em outros sistemas. Muitas vezes algumas funções já existem em outros sistemas e mesmo assim ocorre a replicação destas funcionalidades, principalmente com os requisitos de armazenamento (Arquivos Lógicos). Exemplo: Supondo que vários sistemas realizam cálculos de impostos a serem pagos, mantendo em sua base de dados local uma tabela com as alíquotas dos impostos e as respectivas Guia de Contagem de Pontos de Função 11/39

270 funcionalidades de manutenção destes dados. Por conta de um acréscimo no IOF, diversos sistemas tiveram que sofrer manutenção, em alguns deles pagou-se pelas mesmas funções em várias aplicações: o ALI que armazena as alíquotas e as transações de inclusão, alteração e consulta destes dados. Se estas funcionalidades estivessem centralizadas em um único sistema, as funções de manutenção das alíquotas de impostos (inclusão, alteração e consulta) seriam contadas no projeto de melhoria do sistema responsável por estes dados e os demais contariam apenas um AIE alterado e suas funções específicas impactadas, que seriam contadas de qualquer forma Avaliando apenas as novas funcionalidades e supondo que 4 sistemas fossem afetados, que o Arquivo Lógico fosse de complexidade baixa (7 PF) e que as transações fossem de complexidade baixa (3x 3 PF), para o primeiro cenário haveria um total de 64 PF(1 ALI + 2 EE + 1 CE para cada um dos 4 sistemas), enquanto que no segundo, 31 PF (1 ALI + 2 EE + 1 CE no sistema central e + 1 AIE para cada um dos 3 sistemas restantes). Ou seja, resultaria em uma redução de aproximadamente 50% no total de PF. c) Analisar criticamente os requisitos. Em muitas situações é possível ter uma única função que faça o papel de duas existentes. Isto é muito comum no caso de consultas e relatórios com diferença apenas de alguns atributos apresentados. Ou seja, uma transação mais completa poderia ser elaborada para evitar a criação de várias funções distintas, porém semelhantes. É mais barato pagar pela criação de uma função nova do que por uma manutenção em duas ou mais funções, principalmente a longo prazo. 4.2 Campos Não Editáveis (Read-Only) Para telas de pesquisa, cadastro e alteração que apresentem automaticamente dados preenchidos em campos não editáveis, é importante avaliar a sua necessidade funcional. Cenário I: campo preenchido automaticamente para restringir valores de entrada do usuário, de acordo com o perfil do usuário autenticado. Caminho da Escola CS001 No exemplo apresentado, os campos UF, Tipo de Entidade e Entidade são carregados e preenchidos automaticamente, caso o usuário autenticado no sistema não possua perfil de Gestor. Estas informações são mantidas em uma entidade externa ao sistema e recuperadas conforme o usuário específico. Guia de Contagem de Pontos de Função 12/39

271 Estes são campos do negócio que atravessam a fronteira da aplicação e são utilizados como parâmetros para a funcionalidade de filtro e, portanto, devem ser contados como Tipos de Dado da funcionalidade em questão. Vale ressaltar que o fato destes campos serem carregados automaticamente não é suficiente para identificação de um segundo Processo Elementar para os usuários com perfil de Gestor, uma vez que trata-se de uma facilidade na restrição do escopo da pesquisa. Cenário II: campos preenchidos automaticamente em uma consulta implícita para alteração de dados Em situações como estas, é importante avaliar quais informações apresentadas e não editáveis são realmente importantes para a funcionalidade de alteração. Ou seja, informações que não sejam essenciais para a alteração em si, porém são carregadas anteriormente por uma consulta implícita não devem ser contadas como Tipos de Dado da transação de alteração. Uma dica é separar a funcionalidade de consulta da funcionalidade de alteração. Imaginar uma tela específica de Detalhe, onde todas as informações são apresentadas, e uma segunda tela de alteração onde há apenas os campos essenciais e os editáveis. Desta forma, as informações não essenciais à alteração ficariam apenas na tela de Detalhe enquanto que os campos não editáveis, porém necessários para a transação, não poderiam ser movidas para esta tela de detalhe, permanecendo na tela de alteração. Cenário III: campos de cabeçalho apresentados ao longo de todo o sistema Antes de classificar tal item, é necessário verificar se a apresentação destas informações no cabeçalho atende realmente a requisitos de negócio da aplicação ou se são apenas requisitos não funcionais da mesma. Partindo do princípio que a apresentação dos dados no cabeçalho seja uma necessidade do negócio da aplicação, deve-se observar se o cabeçalho é apresentado independente da funcionalidade acessada, assim como a funcionalidade específica acessada não depende necessariamente do cabeçalho para ser significativa para a aplicação. Ou seja, havendo uma independência entre tais itens, um Processo Elementar específico deve ser identificado para a capacidade de apresentação de dados do cabeçalho, sendo que seus Tipos de Dado e Arquivos Referenciados não devem ser identificados nas demais funcionalidades apenas pelo fato do cabeçalho estar sendo apresentado na mesma tela. 4.3 Subdivisão de uma Funcionalidade em n Funções Para correta quebra de uma funcionalidade em diversos Processos Elementares, é importante avaliá-las a partir de uma perspectiva do negócio, verificando quais funcionalidades são completas e reconhecidas pelos usuários do negócio. Guia de Contagem de Pontos de Função 13/39

272 Cenário I: mais de um Processo Elementar identificado para a funcionalidade SGD 2.0 Listar Demandas No exemplo apresentado, é possível que o usuário homologue, cancele ou suspenda um conjunto de demandas específicas, selecionadas a partir da listagem ilustrada. É importante avaliar se há uma única Função Transacional para todas as três opções (Ex: Avaliar Demanda) ou se cada um dos itens deve ser classificado como um Processo Elementar distinto. Mesmo que o sistema não dispare nenhum controle específico para cada uma das ações, analisando a partir de uma ótica do negócio, é claro para o usuário que estas são atividades distintas que refletem em situações diferentes para o negócio da aplicação. Desta forma, três funções transacionais devem ser identificadas, já que é claro para o usuário a distinção do ato de homologar uma demanda, para o de cancelar e suspender, e vice-versa. Guia de Contagem de Pontos de Função 14/39

273 Cenário II: um único Processo Elementar identificado para a funcionalidade LSE Cadastrar escola e anexo Folha 1 LSE Cadastrar escola e anexo Folha 2 No exemplo apresentado, é disponibilizado ao usuário uma funcionalidade responsável por cadastrar escolas. No entanto, o cadastro é dividido em duas telas, chamadas de folhas. Em situações como esta, é necessário avaliar se cada uma das telas constitui um Processo Elementar, atendendo principalmente ao requisito de ser auto-contido. Neste caso, a primeira coisa a se fazer é a de tentar identificar que razão levou à divisão da funcionalidade em diversas telas. É comum que formulários de cadastro sejam quebrados em etapas com objetivo apenas de tornar a atividade de cadastro mais intuitiva e organizada, ou seja, apenas para atender a requisitos não funcionais. Assim sendo, apenas um único PE pode ser identificado. Caso contrário, se a funcionalidade tenha sido subdividida em diversas telas para atender a uma necessidade do negócio (Ex: Um departamento possui a competência para o preenchimento de uma das telas enquanto que outro departamento para as demais), será caracterizado mais de um PE. Duas dicas gerais para auxiliar o analista de métricas em situações semelhantes são: Verificar se, caso a funcionalidade não fosse fragmentada e houvesse uma única tela, haveria algum impacto no negócio da aplicação ou se a funcionalidade se tornaria apenas menos usual. Verificar se há usuários de áreas de negócio distintas responsáveis por preencher telas específicas da funcionalidade, não tendo competência (mesmo que munidos de todas as informações necessárias) para o preenchimento completo do formulário. Guia de Contagem de Pontos de Função 15/39

274 Voltando ao exemplo do LSE, e aplicando estas duas dicas, é possível verificar que existe apenas um único PE. O usuário não reconhece como uma atividade do negócio apenas preencher uma folha específica do formulário como um processo auto-contido. O usuário visualiza o cadastro de escola como um todo, porém dividido em duas abas para atender a requisitos não negociais (Ex: Layout obrigatório). 4.4 Impressão de Termos e Formulários Para correta contagem dos Tipos de Dado em funções responsáveis pela emissão de termos e formulários, é importante verificar se estes possuem campos recuperados de Arquivos Lógicos Internos ou Arquivos de Interface Externa (Arquivos Referenciados da função) ou até mesmo gerados dinamicamente. Cenário I: formulário composto por dados resgatados de vários Arquivos Lógicos Caminho da Escola CS001 No exemplo apresentado, existem tanto campos resgatados de Arquivos Lógicos do sistema, como um dado derivado (Valor Solicitado). Portanto, deve-se identificar em quais Arquivos Lógicos os campos resgatados são armazenados para que estes sejam identificados como Arquivos Referenciados da função. 4.5 Envio de Muitas funções possuem embutidos em seu processamento, o envio de s de notificação ao usuário final. Guia de Contagem de Pontos de Função 16/39

275 Cenário I: envio de como conseqüência de um processo SAPE No sistema SAPE 2010 como um todo, diversas funções são responsáveis pelo envio de s ao final do processamento da transação. Como exemplo, tem-se a funcionalidade ilustrada acima. O usuário, ao reiterar a diligência sendo analisada, faz com que o sistema envie um automaticamente aos seus responsáveis, informando sobre a ação executada. O envio do é sempre acionado após a efetivação de tal transação, sendo parte da respectiva funcionalidade e não um Processo Elementar independente. A atividade que é significativa para o usuário é o conjunto de ações referentes à efetivação e ao envio do , e não ambas isoladamente. Desta forma, tanto os Arquivos Referenciados como os Tipos de Dado utilizados pela ação de envio de devem ser contabilizados na transação responsável pelo seu disparo. Cenário II: envio apenas do , independente de outras transações Ainda com base no exemplo apresentado no cenário anterior, é possível identificar uma funcionalidade responsável apenas pelo re-envio do de notificação, sem que seja necessária a re-efetivação da transação. Partindo do princípio que tal funcionalidade tenha sido criada devido a solicitações funcionais do negócio, a ação de envio de , independente de quaisquer outras ações do sistema é consistente, significativa para o usuário e completa em si e, portanto, deve ser classificada como um novo Processo Elementar. Note que a identificação da transação referenciada no primeiro cenário não é alterada. Apenas uma nova função transacional passa a ser identificada. 4.6 Identificação de Tipos de Registro e Arquivos Lógicos Para correta contagem dos Tipos de Registro e Arquivos Lógicos, é importante verificar as entidades do negócio e suas respectivas dependências funcionais. Guia de Contagem de Pontos de Função 17/39

276 CAE Virtual Fragmento MER No exemplo são apresentadas quatro tabelas distintas, porém apenas um único Arquivo Lógico pode ser identificado, este com apenas dois Tipos de Registro. Note que as tabelas SITUACAO_MANDATO e TIPO_ATO_CAE são compostas apenas por código e descrição, sendo um exemplo clássico de Dados de Código e, portanto, não podem ser reconhecidas como Arquivos Lógicos ou Tipos de Registro de um Arquivo Lógico. Já a tabela CONSELHO_AMPARO_LEGAL, a partir do ponto de vista do negócio da aplicação, representa uma entidade do negócio dependente da entidade descrita pela tabela CONSELHO. Esta conclusão pode ser obtida ao analisarmos as regras e procedimentos do negócio do sistema, assim como a forma pela qual as informações mantidas em ambas as tabelas são cadastradas e atualizadas, a partir da visão do usuário. Ou seja, ambas constituem um único Arquivo Lógico e este por sua vez é composto por dois Tipos de Registro. Note que não há requisitos transacionais responsáveis por manter especificamente as informações armazenadas na tabela CONSELHO, isoladamente às informações mantidas na tabela CONSELHO_AMPARO_LEGAL (e vice-versa). Este é um forte indício de que a separação feita no modelo de dados ocorreu apenas para atender a requisitos não funcionais (Ex: Normalização). Indício que se confirma ao analisarmos a relação de dependência entre estas informações perante uma ótica do negócio, sem levar em consideração a solução técnica e observando apenas a forma pela qual o sistema trata estes dados com o usuário. A seguir é apresentada a tela de cadastro responsável por cadastrar dados em ambas as tabelas: Guia de Contagem de Pontos de Função 18/39

277 CAE Virtual Manter Dados CAE Conforme ilustrado, existe apenas uma única tela encarregada pelo cadastramento de tais informações. Os dados referentes ao conselho em si (parte superior) e ao amparo legal (parte inferior da tela) são dependentes, sendo reconhecidas como um único requisito de armazenamento de dados para o negócio da aplicação. É necessária uma atenção especial com relação à distinção dos conceitos de Dependência Funcional e Obrigatoriedade de Relacionamento. Observe que o último restringe associações dentro de um modelo de dados, ou seja, uma entidade deve obrigatoriamente apontar para um registro em outra entidade, porém isto não é suficiente para declará-las como dependentes funcionais entre si. Uma entidade pode ter significado para o negócio independente de qualquer outra, mesmo que esta possua diversas obrigatoriedades de relacionamento (restrições de FK), conforme apresentado a seguir: SBA Fragmento MER Guia de Contagem de Pontos de Função 19/39

278 Neste caso, a entidade do negócio Alfabetizando não depende funcionalmente de um município para existir. Este é apenas um de seus atributos que aponta para outra entidade do negócio desta aplicação e, portanto, Arquivos Lógicos distintos devem ser identificados. 4.7 Conversão de Dados Para correta medição das funções de conversão, é importante verificar se a atividade relacionada realmente deve ser classificada como uma função de conversão de dados ou se trata apenas de uma atividade de suporte, que não pode ser classificada como uma função (vide mais detalhes a seguir). As funções de conversão de dados devem possuir dados atravessando a fronteira da aplicação e serem descartáveis (executadas uma única vez em produção). Este tipo de funcionalidade possui a intenção primária de manter um ou mais ALIs da aplicação e, portanto, são classificadas como Entradas Externas. Também é importante atentar-se à análise correta dos relatórios comumente emitidos por estas funcionalidades. Estes são conseqüência da atividade de migração, não sendo completos em si (auto-contidos) e, portanto, não devem ser medidos como uma nova função, independente da migração em si. A dica geral é fazer a analogia entre a funcionalidade de conversão com a atividade de migração de registros de forma manual (usuário entrando com dados por meio de uma tela de cadastro). Se não houvesse a funcionalidade, o usuário informaria os campos na tela (dados entrando pela fronteira) e faria toda esta atividade uma única vez (descartável), já que, após concluída a migração, os registros passariam a ser cadastrados conforme o negócio da aplicação. Ou seja, a função de conversão de dados é responsável apenas por automatizar a execução de toda a atividade de entrada de dados, caracterizada pela busca dos dados que entrarão pela fronteira da aplicação em alguma fonte externa (Ex: planilhas, tabelas, arquivos txt) e pelo fato de ser descartável, já que não terá mais utilidade após a sua execução. Cenário I: migração de dados dissociada de projeto O Sistema de Consulta de Distribuição do Livro é uma pequena aplicação de apoio à operação da distribuição de materiais didáticos entre as escolas. Porém este será descontinuado e substituído por um novo módulo no próprio SIMAD Sistema de Material Didático. Devido a restrições do negócio, a migração dos dados já cadastrados no Sistema de Consulta de Distribuição do Livro não será realizada em conjunto com a criação do próprio módulo, sendo necessário aguardar certo período do ano para que os dados sejam migrados de forma consistente e sem impacto na execução das atividades do negócio relacionadas. Desta forma, em um primeiro momento foi solicitada a criação do novo módulo e posteriormente foi gerada uma nova demanda referente à migração de dados. Neste caso, a migração de dados será identificada normalmente como uma função de conversão e deverá ser medida em PF. O fato de a migração ter sido solicitada isoladamente em nada afeta a análise de Pontos de Função. Esta seria medida da mesma forma caso fizesse parte da demanda que solicitou a criação do novo módulo. O cuidado a ser tomado é com relação à recontagem da mesma migração como uma função de conversão, caso esta já tenha sido medida e paga anteriormente. Cenário II: migrações de dados frequentes/periódicas Anualmente uma aplicação do FNDE deve realizar a migração/importação de dados específicos do MEC. Estas cargas são executadas uma única vez ao ano, porém sempre ocorrem no mês de Janeiro, sendo que a cada ano esta carga de dados passa por alterações em seus campos, já que estão sujeitos a alterações feitas pelo MEC. Guia de Contagem de Pontos de Função 20/39

279 Nesta situação, não há função de conversão de dados. As migrações são executadas periodicamente (mesmo que em períodos longos de um ano), o que confronta o caráter descartável das funções de conversão. Há na realidade uma função transacional responsável pela carga dos dados na aplicação do FNDE, que fatalmente passará por manutenções funcionais ao início de cada ano, salvo situação em que esta atividade seja executada diretamente pela equipe de desenvolvimento, sem que haja uma funcionalidade responsável por tal tarefa (um exemplo disso é a carga do Censo Escolar, que é executada anualmente pela equipe de banco de dados, não havendo uma funcionalidade para automatizar este processo). Note que, caso fossem identificadas várias funções de conversão ao invés de um Processo Elementar sendo modificado - além da distorção conceitual e possível impacto na medição da baseline - nenhum deflator seria aplicado a estas funções. 4.8 Middleware Para correta medição de aplicações de middleware, é essencial avaliar e definir corretamente a sua fronteira e os usuários que interagem com o sistema. Como o negócio da aplicação é geralmente servir como um intermediário para comunicação entre dois ou mais sistemas, caso a fronteira do middleware não esteja clara, esta poderá englobar parte das fronteiras das aplicações responsáveis por interagir com o sistema, comprometendo a medição realizada. Da mesma forma, caso os usuários da aplicação não sejam identificados corretamente, a quantidade de funções identificadas não representará a realidade. Se houver usuários que não foram reconhecidos durante a medição, a quantidade de funções identificadas para aplicação será inferior à quantidade real, enquanto que se forem identificados usuários inexistentes, diversas funções serão identificadas erroneamente. Cenário I: sistema intermediário Dentre as várias implementações possíveis para este tipo de solução, a mais comum é aquela em que o sistema é utilizado para conectar duas outras aplicações separadas. Assim, os usuários de middlewares são, geralmente, outras aplicações. Exemplo Middleware Neste exemplo, duas aplicações, X e Y, precisam trocar informações. Porém, elas não utilizam a mesma linguagem, precisando de uma aplicação intermediária (middleware) para que elas possam se comunicar. Deste modo, conforme figura acima, a Aplicação X envia uma Requisição A para o middleware e este a traduz, registra no log e a envia à Aplicação Y, de modo que Y consiga interpretar e processar. A aplicação Y processa esta mensagem e retorna uma Resposta M ao Middleware para traduzi-la e enviá-la à Aplicação X, para que este processe o retorno e conclua a operação. Guia de Contagem de Pontos de Função 21/39

280 Fronteira da Aplicação: Com base no cenário apresentado, é possível verificar que as aplicações em interface com o middleware são os usuários. Eles, logicamente, reconhecem as traduções que são enviadas e recebidas. Desde que o propósito seja medir o tamanho da aplicação de middleware, a fronteira é limitada para as funcionalidades fornecidas pelo sistema intermediário. Arquivos Lógicos Internos: De acordo com os requisitos, todas as transações recebidas e enviadas para o roteador são registradas no arquivo de log do roteador. Com isso, pode-se concluir que o log do roteador é um ALI para a aplicação do middleware. Arquivos de Interface Externa: Como nenhum Arquivo Lógico externo à fronteira do sistema de middleware é referenciado, nenhum AIE pode ser identificado. Entradas Externas: Nenhuma EE pode ser identificada, pois todas as transações têm intenção de enviar dados para fora da fronteira do middleware. Saídas Externas: Os requisitos do usuário identificam as seguintes funcionalidades: Conversão e envio de uma mensagem da Aplicação X para a Aplicação Y. Conversão e envio de uma mensagem da Aplicação Y para a Aplicação X. Consultas Externas: Nenhuma CE pode ser identificada, pois todas as transações mantêm o log do roteador. Cenário II: webservice dentro da fronteira da aplicação Em uma aplicação há a necessidade de disponibilizar informações específicas do negócio do sistema para outras aplicações. A fim de atender a esta necessidade, foi implementado um WebService encarregado de publicar as informações pertinentes aos seus respectivos sistemas. Esta decisão foi tomada pelo gerente responsável pelo projeto com intuito de facilitar futuras manutenções e o acesso externo dos demais sistemas. Note que, para o cenário descrito acima, o WebService em si não é caracterizado como uma aplicação distinta, com uma fronteira própria. Este é apenas a solução técnica adotada para disponibilizar os dados necessários às diversas aplicações. Inclusive, outras soluções poderiam ter sido utilizadas, sem que houvesse qualquer tipo de impacto nos requisitos funcionais da aplicação (Ex: tabelas compartilhadas; arquivos txt; acesso direto a base de dados; etc). A correta definição da fronteira é essencial e merece especial cuidado. Observe que, ao contrário do cenário apresentado no tópico anterior (Middleware) onde há uma fronteira própria para a aplicação de middleware (cujo negócio/objetivo é justamente servir como uma aplicação intermediária entre um ou mais sistemas), neste caso o WebService foi implementado apenas com intuito de atender a uma necessidade específica da aplicação como um todo. O WebService é apenas um dos componentes técnicos utilizados pela aplicação, cujo respectivo negócio não é servir como intermediária entre outros sistemas. No que diz respeito à contagem, para cada um dos sistemas e conjunto de informações disponibilizados, haverá (desde que atenda as respectivas regras de identificação, expostas no Manual de Práticas de Contagem) uma função transacional do tipo CE ou SE. No entanto, caso a intenção primária da função não seja a de disponibilizar informações a outras aplicações, e sim a de manter um ou mais Arquivos Lógicos ou alterar o comportamento do sistema, a função deverá ser classificada como uma EE. Nestas situações, a transação funciona como uma transação de cadastro, porém disponibilizada via WebService. Guia de Contagem de Pontos de Função 22/39

281 Para correta identificação das transações, a dica geral é fazer uma analogia das informações sendo disponibilizadas com telas de relatórios comuns, acessadas por usuários finais (pessoas e não sistemas). Ou seja, se o usuário que necessita da informação não fosse outra aplicação, a mesma funcionalidade poderia ser desenvolvida como um relatório em que todas as informações necessárias seriam apresentadas. Lembre-se: as regras de identificação e unicidade são as mesmas, porém adotando uma solução (técnica) específica. Utilize a dica descrita no parágrafo anterior durante a realização da contagem, evitando a identificação errônea de vários Processos Elementares para uma única consulta e vice versa. 4.9 Processos Sem Interface Gráfica (batch) Para correta medição de rotinas puramente batch, é importante verificar quais usuários estão interagindo com o sistema durante a execução da rotina e se há dados passando pela fronteira da aplicação, seja entrando ou saindo. É comum a supressão deste tipo de rotinas em contagens, alegando que este tipo de processamento simplesmente não é passível de contagem. No entanto, esta é uma inverdade que pode resultar em um impacto drástico na medição final de uma demanda. O fato de uma rotina não possuir interface gráfica de entrada ou d e saída com a pessoa do negócio que utiliza o sistema não é suficiente para descartar a funcionalidade durante a medição. O conceito de Usuário para a APF não se restringe apenas a pessoas físicas, englobando também outros sistemas que se comuniquem com a aplicação sendo analisada. Ou seja, rotinas batch sem interação humana, mas que são responsáveis pelo tráfego de informações entre sistemas distintos (que é um cenário comum), podem ser medidas, desde que atendam às regras de identificação de um Processo Elementar. Ao se deparar com este cenário, o primeiro passo que o analista deve realizar é identificar os possíveis usuários que estejam se comunicando com o sistema sendo medido, por meio desta rotina batch. Se não houver nenhum usuário (Ex: rotina que ordena os registros cadastrados no dia por ordem alfabética, sem emitir nenhum tipo de saída), não há Processo Elementar. A APF é baseada na visão do usuário, o que impede que haja uma funcionalidade totalmente interna, sem nenhum tipo de interação com ao menos um usuário (seja uma pessoa física ou outro sistema). Havendo um usuário interessado na execução da rotina, é necessário verificar se esta atende às regras de identificação de um PE, assim como em qualquer outra funcionalidade transacional. A dificuldade pode estar em entender a lógica da funcionalidade que possui apenas outro sistema como usuário para que a atividade seja executada de forma automatizada, porém a análise é exatamente a mesma. A dica geral é imaginar que o usuário sistema não existisse e o processo fosse manual. Ou seja, ao invés de outra máquina interagindo via rotina batch, haveria uma pessoa entrando ou recebendo dados por meio de telas, tornando a análise da funcionalidade mais simples. Cenário I: rotina batch não-mensurável A implementação de rotinas de carga/limpeza de banco de dados programadas para serem executadas periodicamente e, normalmente, fora do horário comercial, é uma prática comum em qualquer instituição. Não havendo nenhum tipo de relatório ou sendo disparado como conseqüência a execução da rotina, não há funcionalidade passível de medição, uma vez que não existem dados atravessando a fronteira da aplicação. Guia de Contagem de Pontos de Função 23/39

282 Note que mesmo sendo mantido um registro em uma tabela de Log, por exemplo, a análise continua a mesma. A atividade de registrar uma informação em um ALI não caracteriza a entrada ou saída de dados pela fronteira, até porque, como o próprio nome diz, este é um arquivo interno ao sistema. O mesmo ocorre com a existência de dados sendo resgatados de AIEs. O fato de uma transação possuir um AIE como arquivo referenciado não caracteriza a entrada ou saída de dados pela fronteira. Lembre-se: os dados devem entrar ou sair para usuários do sistema. Cenário II: rotina batch mensurável Agora supondo que, ao final do dia, o sistema execute uma rotina batch responsável por verificar todos os processos administrativos registrados no dia e disparar um às partes envolvidas. Note que neste caso há dados atravessando a fronteira. O se assemelha a um relatório, onde o usuário consultaria todos os novos processos administrativos que o envolva, por meio de telas. A diferença é que a atividade de verificação é automatizada e o relatório é disparado via aos interessados. Cenário III: rotina batch como parte de outros processos Outra situação extremamente comum é aquela na qual uma funcionalidade é disponibilizada via interface gráfica, porém, do ponto de vista do negócio, esta funcionalidade só é executada parcialmente, sendo consolidada ao final do dia com a execução de uma rotina batch. Supondo uma situação onde o usuário realize uma transferência bancária, porém esta só seja efetivada ao final do dia por uma rotina batch. Partindo do princípio que a atividade apenas de solicitação não seja significativa para o negócio, que só entende esta atividade como completa quando a transferência é efetivamente realizada, o PE é composto de duas partes, uma onde o usuário interage diretamente com o sistema, e outra puramente batch. Como a funcionalidade como um todo é significativa para o usuário, caso a transferência fosse realizada em tempo real, em nada afetaria o negócio da aplicação. A quebra da atividade ocorre para atender a requisitos não-funcionais (Ex: capacidade de processamento limitada). Ou seja, ao identificar esta funcionalidade, contar apenas os TDs e ARs da parte gráfica está incorreto. Durante a execução da rotina, pode haver ARs que não são acionados na primeira etapa da funcionalidade e que devem participar da contagem sendo realizada. Além disso, atente-se à contagem dos TDs. Caso existam campos adicionais sendo trabalhados pela rotina batch, mas que não atravessem a fronteira em momento algum, estes não devem ser contados, assim como preconiza as regras de identificação de TDs expostas no CPM. Note também que neste tipo de solução é comum a utilização de tabelas/arquivos temporários, criados apenas para armazenar as informações enquanto a rotina não é executada. Geralmente este tipo de implementação é puramente técnica e não deve interferir na medição funcional Data Warehouse e BI Para a correta medição de aplicações de Data Warehouse, é importante ater-se aos conceitos da técnica de Análise de Pontos de Função, evitando vícios de contagem devido à implementação técnica atípica deste tipo de sistema. A APF mede software, independente de qual seja a tecnologia e da maneira pela qual este tenha sido implementado. Ou seja, por mais peculiar que este tipo se aplicação possa ser, ela pode ser medida em PF. Projetos de Data Warehouse contêm muitos documentos que o Analista de Métricas pode usar para auxiliar na contagem do ponto de função. Alguns dos documentos mais úteis são os diagramas de modelo de dados, que ajudam a determinar funções de dado e de transação. Guia de Contagem de Pontos de Função 24/39

283 Cenário I: exemplo de data warehouse Function Points & Counting Enterprise Data Warehouses Exemplo DW Fronteira da Aplicação: Assim como nas demais aplicações, a definição da fronteira é uma atividade de extrema importância para a medição de DWs. É vital enquadrar todos os componentes próprios da aplicação dentro de sua fronteira, deixando claros aqueles elementos que extrapolam a fronteira do DW (Ex: Sistemas de origem de dados e Data Marts). Caso haja alguma ferramenta/componente web responsável por tornar as informações mais acessíveis aos usuários, este deverá ser analisado com intuito de posicioná-lo corretamente na definição da fronteira. Algumas dicas para ajudar nesta decisão são: o Se um Website central é usado para acessar vários DWs dentro da empresa e este é mantido por uma equipe, essa é uma boa indicação de que a ferramenta é uma aplicação separada, cuja intenção primária é fornecer acesso aos DWs. o Se a ferramenta foi construída para fornecer capacidades de relatório para um DW específico, e é mantida pela mesma equipe responsável pelo DW, provavelmente, seria contada como parte do mesmo aplicativo. ATENÇÃO: A fronteira do aplicativo não se baseia necessariamente em como a organização do software é gerenciada. Porém, conhecer quem desenvolveu o componente que fornece acesso a um DW em particular pode ser útil quando se define a fronteira da aplicação. Analisando seus Componentes: Alguns elementos presentes em aplicações de DW são tipicamente técnicos, criados para garantir o funcionamento da solução, enquanto que outros possuem significado para o negócio da aplicação e, portanto, devem ser levados em consideração durante o processo de medição. Elementos puramente técnicos: o Staging Areas o Depósito de Dados Operacionais (ODS) o Data Warehouse Guia de Contagem de Pontos de Função 25/39

284 Elementos com significado para o negócio: o Tabelas Fato: Caracterizam, em conjunto com as tabelas dimensionais, ALIs da aplicação. o Tabelas Agregadas: Podem ou não ser contadas, dependendo da razão de sua existência. Se tiver sido criada para atender a requisitos do negócio, poderá participar da medição como um ALI. o Tabelas de Existência: Podem ou não ser contadas. Se atender a necessidade de documentar a existência de um evento, participará da contagem (geralmente como um Arquivo Lógico de complexidade baixa). o Tabelas Dimensionais: Caracterizam, em conjunto com a tabela fato, um ALI da aplicação. Ou seja, cada tabela dimensional é um TR do ALI principal, que é a tabela Fato. o Tabelas de Visão/Visualização: Podem ser identificadas na medição como CE ou SE, caso sejam criadas com intuito de fornecer informações para outro aplicativo, fora da fronteira do DW em questão. o Metadados: Podem participar da medição como ALIs caso estejam relacionados à questões negociais da aplicação (Ex: dicionário de dados, proprietários de dados e assuntos sobre a área de informação) o ETL Extrair, Transformar e Carregar: Participam da medição como única EE para cada ETL. o Relatórios Ad-Hoc: Não participam da contagem de PF, salvo no caso em que haja uma funcionalidade oferecida ao usuário para criar seus próprios relatórios ad-hoc. o Relatórios Programados: Caso atendam às regras de identificação de um PE, estes relatórios participarão da medição como CE ou SE. o Funções Administrativas: Participarão da medição caso a sua natureza esteja relacionada ao negócio da aplicação. o Funções de Metadados: Podem ou não ser contadas. Caso tenham sido desenvolvidas para apoiar um usuário do aplicativo de forma negocial, serão identificadas como PEs. Tabelas Fato x Tabelas Dimensionais: Fisicamente, tabelas fato contêm somente os TDs requeridos para representar alguma medida do negócio e são rodeadas por tabelas dimensionais que permitem descrever um evento em particular. Para cada conjunto de tabelas fato e suas respectivas dimensões deve-se identificar um ALI. Este por sua vez possuirá um TR adicional para cada dimensão associada à tabela fato. Note que apenas o conjunto (fato + dimensões) é significativo ao usuário. Uma contagem de TDs tipicamente incluirá campos da entidade da tabela fato e da entidade dimensional, no entanto, certifique-se de contar somente os requeridos para a entidade fato em análise. ETL Extrair, Transformar e Carregar: ETL é o conjunto de transações de banco de dados usado para extrair informações de um banco de dados, transformá-las e carregá-las em um segundo banco de dados. As fontes de dados estão em aplicativos ou sistemas que são externos ao DW (fora da fronteira). Lembre-se que a intenção primária dessas transações é manter dados lógicos (ou alterar o comportamento do sistema). As lógicas que envolvem os processos de transformação e carga de dados são secundárias à sua intenção primária. Guia de Contagem de Pontos de Função 26/39

285 Ou seja, não conte três Processos Elementares separados para cada uma das atividades (Ex: uma EE de Extração, uma EE de Transformação, e uma CE de Carregamento). Apenas o conjunto é auto-contido, uma vez que todas as três etapas são requeridas para completar a transação. Arquivos de Interface Externa: Durante o processo de ETL, caso haja a necessidade do processo acessar informações para fins de referência e validação, a origem destes dados deve ser analisada a fim de verificar se atende às regras de identificação de um AIE. Note que os dados sendo diretamente extraídos, transformados e carregados pelo processo de ETL constituem TD da transação e não AIEs como Arquivos Referenciados da função. Atente-se também ao fato de que em muitas situações estas tabelas de origem negocial externas à aplicação de DW são copiadas, fisicamente (sem nenhuma lógica especial de processamento) para dentro do próprio DW, a fim de atender a requisitos não-funcionais da aplicação (Ex: desempenho; arquitetura; etc) e, portanto, devem ser reconhecidos normalmente como AIEs da aplicação quando utilizados para fins de referência e validação Workflow Para correta medição de sistemas de workflow, é essencial avaliar e definir corretamente a sua fronteira, seus grupos de usuários e a visão de suas transações (a partir de uma perspectiva do negócio). Um sistema de workflow é a automação de um processo de negócio, no todo ou em parte, durante o qual documentos, informações ou tarefas são passadas de um participante para outro, para ação em conformidade com um conjunto de regras específicas. Ferramentas cuja finalidade seja a de criar/manter aplicações de workflow de forma automatizada não devem ser enquadradas na mesma fronteira que o workflow em si. A maneira pela qual o fluxo de trabalho será construído (manualmente ou por meio de uma ferramenta de apoio) não deve interferir na definição da fronteira e escopo da contagem, uma vez que o workflow será o alvo de medição e não a ferramenta criada para automatizar a construção e manutenção destas aplicações (que pode ou não ser utilizada). Ou seja, deve-se avaliar as funcionalidades disponibilizadas ao usuário por meio do workflow e não a forma pela qual estas funções foram disponibilizadas. No entanto, o maior desafio na medição deste tipo de aplicação está na identificação de suas funções transacionais. O erro mais comum cometido está relacionado à identificação da menor unidade de atividade com significado para o usuário, uma vez que as funcionalidades não são quebradas corretamente em diversos PEs até a sua menor atividade. Cenário I: exemplo de workflow Cenário: O processo de negócio Solicitação de Viagem, é composto por diversas tarefas que, por definição, devem acontecer em um ponto consistente no processo e com um conjunto definido de entradas e saídas, antes e depois da execução da atividade. Este processo é composto pelas seguintes funcionalidades: Incluir Solicitação de Viagem, Editar Solicitação de Viagem, Concluir Solicitação de Viagem, Consultar Detalhes da Solicitação de Viagem e Pesquisar a Solicitação de Viagem. Cada uma destas funcionalidades é completa em si mesma e deixa a aplicação em um estado consistente. Por exemplo, o usuário pode incluir uma solicitação de viagem e salvar seus dados como um rascunho e encaminhar adiante. Guia de Contagem de Pontos de Função 27/39

286 O processo de negócio Solicitação de Viagem, de forma genérica, incluindo todas as atividades relacionadas à solicitação, não é a menor unidade de atividade com significado para o usuário final, apesar de ser completa e deixar o sistema em um estado consistente. A atividade de Editar Solicitação de Viagem parte da tarefa Solicitação de Viagem também é completa e deixa o sistema em estado consistente. Uma vez concluída, o usuário pode consultar em outro momento posterior o trabalho que fez, pode alterar novamente os dados que informou e passar o documento adiante. Não existe atividade menor do que esta que seja completa. Preencher o centro de custo, por exemplo, dissociado do preenchimento dos demais dados não é completo de uma perspectiva do negócio. Assim, a inclusão da solicitação de viagem é um processo elementar, bem como: Solicitação de viagem Incluir Solicitação de viagem Editar Solicitação de viagem Concluir Solicitação de viagem Consultar detalhes Solicitação de viagem Pesquisar Vale ressaltar que, caso fosse utilizada uma ferramenta de automação, a análise feita sobre o cenário apresentado continuaria a mesma. São as funcionalidades disponibilizadas ao usuário para que este atenda à sua necessidade do negócio que serão avaliadas, e não a forma pela qual estas foram geradas. Este conceito também é aplicado sobre a avaliação da unicidade das funções. Portanto, caso haja outra pesquisa relacionada a um outro fluxo específico do workflow, esta deverá ser identificada como uma nova transação (respeitando as regras impostas pelo CPM), independente da ferramenta de apoio gerá-las de forma similar Views/Visões em Bancos de Dados Para correta medição de views em bancos de dados relacionais, é importante analisar as causas que justificaram a sua criação e a quais objetivos estas visam atender. De modo geral, as visões são criadas para atender a requisitos técnicos do sistema (Ex: consolidar dados, facilitar a recuperação de informações, melhorar o desempenho da aplicação, etc) e, portanto, uma view em si não deve influenciar o valor da contagem de Pontos de Função. No entanto, esta pode indicar a existência de um ou mais Arquivos Lógicos, servindo como um indício no momento da identificação das funções de dado da aplicação. Cenário I: views/visões úteis durante a identificação de arquivos lógicos Em diversos sistemas do FNDE, foram criadas views públicas (visíveis para todas as aplicações) com intuito de contornar uma restrição de segurança/acesso a bancos de dados de aplicações distintas, onde sistemas externos não possuem acesso direto às informações mantidas na base de outra aplicação. A partir de uma perspectiva do negócio, as views são transparentes, uma vez que são componentes puramente técnicos. Se a restrição de segurança não existisse, as aplicações não necessitariam das visões para acessar as informações desejadas e, portanto, poderiam existir apenas para atender a requisitos de performance, por exemplo. Analisando o motivo pelo qual as views foram criadas, há fortes indícios de que, na contagem da aplicação externa que está acessando a view, deve ser contado pelo menos um Arquivo de Interface Externa para cada view utilizada. É necessário analisar as tabelas e campos que compõem a view e verificar quais entidades do negócio da aplicação estão sendo referenciadas pela visão, além de quais campos são efetivamente utilizados pelas aplicações que utilizam estas views. Guia de Contagem de Pontos de Função 28/39

287 Do ponto de vista da aplicação que mantém a view, a view não pode ser considerada um Arquivo Lógico, uma vez que não representa um requisito do usuário e não é mantida pela aplicação. Cenário II: views/visões não úteis durante a identificação de arquivos lógicos Em diversos sistemas do FNDE, foram criadas views internas com intuito de melhorar o desempenho da aplicação e facilitar a recuperação de dados pela equipe de implementação. A partir de uma perspectiva do negócio, as views são transparentes, uma vez que são componentes puramente técnicos. Se os requisitos não-funcionais que justificaram a criação das visões não existissem, em nada afetaria a aplicação a partir de uma visão do negócio. Analisando o motivo pelo qual as views foram criadas, não é possível concluir que possa haver Arquivos de Interface Externa na aplicação, já que estas são internas ao sistema. Lembrando que não é aconselhável utilizar as views como insumo para a identificação de Arquivos Lógicos Internos, uma vez que estas são puramente técnicas e podem levar a erros de medição. Procure sempre utilizar os insumos mais próximos do mundo lógico da aplicação e evite, se possível, aqueles que estejam muito ligados a solução técnica do sistema. Da mesma forma, neste cenário a view também não pode ser considerada um Arquivo Lógico, uma vez que não representa um requisito do usuário e não é mantida pela aplicação Transações compartilhadas entre várias aplicações Para correta análise sobre funcionalidades sendo compartilhadas entre diversas aplicações, é importante verificar qual a visão do usuário sobre estas funções. Se o usuário reconhecer que está acessando uma transação externa à aplicação que estava utilizando, apenas a função mantida externamente seria reconhecida. Porém existem casos em que há funcionalidades replicadas em diversos sistemas, sem haver uma reutilização das funções já disponíveis em outras aplicações. Apesar de não desejável, é um cenário comum e que acarreta na contagem de mais de uma função transacional. A dica geral para auxiliar na distinção de tais cenários é avaliar se a funcionalidade passou por um processo de desenvolvimento de software ou não. Caso tenha passado, caracteriza uma nova transação, própria da aplicação em que está inserida. Observe que alterações na funcionalidade central não terão impacto sobre esta, que exigirá novas manutenções para se adequar àquela. No entanto, o principal cuidado a ser tomado é com relação à construção de novas funcionalidades. A abordagem descrita acima é útil na verificação das transações em sistemas legados, cujo cuidado para evitar a replicação de funcionalidades não foi tomado. Porém no caso de novas funções, devese evitar a replicação de funcionalidades e as transações corporativas devem ser utilizadas sempre que possível. Caso esta orientação não seja seguida, o fornecedor deverá realizar as correções devidas como parte da garantia pelo serviço prestado Consultas com múltiplas mídias Basicamente a questão das múltiplas mídias consiste em um processo com a capacidade de gerar a sua saída ou processar a entrada de diversos meios (mídias) distintos e a divergência que surge é com relação à quantidade de Processos Elementares que deverão ser identificados (uma única transação ou um PE para cada mídia). O IFPUG reconhece duas abordagens possíveis para a questão: única instância e múltiplas instâncias para as funções que possuem várias mídias. A abordagem usada é decisão local de cada organização. Para cobrir essa lacuna no manual do IFPUG, serão contadas todas as funções que deverão ser desenvolvidas para atender a uma mídia específica, desde que se trate de um requisito funcional Guia de Contagem de Pontos de Função 29/39

288 especificado pelo usuário, enquanto que aquelas que forem disponibilizadas automaticamente por meio de componentes, não participarão da medição. A orientação é verificar quais funcionalidades devem ser testadas, com base em seus casos de teste. Esta orientação está em acordo com o descrito no próprio Manual de Práticas de Contagem: Outra indicação de que uma função de transação deve ser contada seria a cobertura de casos de testes. Um único grupo de casos de testes indicaria que um único processo elementar foi alterado. Cenário I: relatório com múltiplas mídias Um relatório em forma de lista é gerado a partir de uma funcionalidade específica presente do sistema SegAdm. Além dos valores apresentados em tela, é possível exportar os resultados listados para uma planilha Excel, conforme ilustrado a seguir: SegAdm Manual do Usuário A funcionalidade responsável pela apresentação da lista em tela é facilmente identificada como um Processo Elementar, porém a habilidade de exportar o resultado para uma planilha Excel exige uma análise um pouco mais apurada. Seguindo a orientação apresentada anteriormente, deve-se verificar se a capacidade de exportação foi disponibilizada por meio de um componente ou framework específico (onde apenas parâmetros de configuração são definidos para que a opção fique disponível) ou se esta funcionalidade passou por um processo de desenvolvimento de software. A orientação é verificar os casos de teste utilizados e verificar a forma pela qual a funcionalidade foi tratada durante a sua criação. Havendo casos de teste específicos para a habilidade de exportação, há um forte indício de que esta funcionalidade passou por um processo de desenvolvimento e não foi disponibilizada apenas por meio de uma configuração em um componente/framework da aplicação. Desta forma, a função de exportação seria reconhecida como um PE da aplicação. Guia de Contagem de Pontos de Função 30/39

289 4.15 Funções transacionais acessadas por diversos perfis de usuário Sistemas com vários perfis de usuário costumam ter transações (telas) compartilhadas por mais de um perfil. Normalmente cada perfil de usuário costuma representar um tipo de usuário no mundo do negócio tratado pelo sistema (exemplo em uma agência bancária: cliente, escriturário, caixa, tesoureiro, gerente). E cada tipo de usuário tem seus requisitos para o sistema; alguns requisitos são comuns a vários tipos de usuário e outros são específicos. Cabe ao analista do sistema identificar os requisitos comuns a estes vários tipos de usuário e avaliar se é interessante tratá-los como um único requisito. Quando os requisitos são idênticos, esta deveria ser a abordagem seguida. Quando há algumas pequenas diferenças nestes requisitos comuns, mais análise é necessária. A decisão de tratar como requisitos distintos implicará na construção de mais artefatos no projeto, como por exemplo, diferentes casos de uso e telas distintas no protótipo. Basicamente esta é tipicamente uma decisão de modelagem de processos de negócio (e que foge ao escopo deste documento). Mas qualquer que seja a decisão tomada pelo analista do sistema, ela é dependente de aprovação (seja por parte do gestor do negócio, do analista de negócio, do usuário ou do patrocinador do projeto). Ou seja, esta decisão acaba se consolidando como a visão do usuário. O manual do IFPUG, nas regras de identificação do processo elementar, diz que os requisitos funcionais do usuário devem ser decompostos nas menores unidades de atividade com significado para o usuário, que constituam uma transação completa, que sejam auto-contidas e deixem a aplicação num estado consistente. E nas regras de unicidade do processo elementar, quando se comparam dois processos com o objetivo de identificar se são distintos ou não, deve-se verificar se possuem: o mesmo conjunto de tipos de dados e o mesmo conjunto de arquivos referenciados e o mesmo conjunto de lógicas de processamento. Importante destacar que um processo pode ter pequenas variações nestes itens, porém isto não é suficiente para quebrar este processo em vários. A regra de unicidade não é para identificar novos processos, mas apenas para diferenciar processos previamente identificados (pelas regras de identificação). Voltando então à questão da transação acessível por mais de um perfil de usuário: para se decidir se conta-se um ou mais processos; deve-se buscar no projeto o(s) requisito(s) que deu(ram) origem a ela. Os requisitos aprovados é que servirão de base para esta decisão. Mas vale ressaltar que a decisão de modelar um ou vários requisitos deve representar da melhor forma a necessidade do usuário. Esta não deve ser uma decisão motivada apenas por requisitos não funcionais (ex: clareza na documentação, facilidade de leitura). Para sistemas legados para os quais não esteja disponível a documentação dos requisitos, a diretriz sugerida é seguir o que o sistema oferece atualmente ao usuário: se uma tela é acessível a vários usuários e há a alguns campos ou lógica de processamento com pequenas variações, conta-se uma transação para todos os perfis Consultas/Pesquisas com diversas opções de filtro Para correta análise de funcionalidades de pesquisa, compostas por diversos campos e opções de filtro, é necessário verificar o seu requisito funcional e o que efetivamente foi solicitado pelo usuário da aplicação. O mais importante é conseguir separar corretamente quais opções adotadas durante a construção da funcionalidade foram tomadas com base em requisitos não-funcionais, evitando a contagem de diversas funções transacionais em situações em que um único Processo Elementar pode ser identificado. Guia de Contagem de Pontos de Função 31/39

290 Cenário I: Consulta com um único Processo Elementar O usuário solicita uma funcionalidade que será responsável pela consulta de sistemas a partir de sua sigla ou gerente responsável pela aplicação. O retorno da pesquisa, independente da opção de filtro selecionada, é sempre o mesmo. A funcionalidade foi construída e disponibilizada ao usuário conforme ilustrado a seguir: Observando apenas a funcionalidade já construída, pode-se chegar à interpretação errônea de que há dois PE distintos (Consultar por Sigla e Consultar por Gerente), uma vez que, a princípio, haveria a quebra de unicidade por conta dos tipos de dados distintos (caso estes não fossem replicados no retorno da pesquisa) e lógica de processamento distinta para cada caso. No entanto esta é uma interpretação incorreta e que pode acarretar em uma grande distorção na mensuração deste tipo de funcionalidade. O que o usuário solicitou é que deve ser a informação utilizada como insumo para a medição sendo realizada. O requisito do usuário é que determinará a quantidade de Processos Elementares existentes e não a forma pela qual a solução foi construída. Neste exemplo, não há razões funcionais para que a consulta seja quebrada em duas transações distintas. A dica geral é sempre fazer a analogia com uma tela de pesquisa em que todos os campos estivessem sempre disponíveis e avaliar qual o impacto no negócio da aplicação. Desta forma, decisões não-funcionais tomadas durante a implementação da funcionalidade ficam mais evidentes (Ex: Limitação de espaço em tela; Melhorar a usabilidade do sistema; etc). Note que para este exemplo, a tela poderia ter sido construída da seguinte forma, atendendo o requisito funcional da mesma maneira: Cenário II: Consulta com vários Processos Elementares O usuário solicita uma consulta de correntistas por Nome e CPF para os usuários com perfil de Atendente, e também por Saldo em Conta, caso o usuário possua perfil de Gerente. O retorno da pesquisa, independente da opção de filtro selecionada, é sempre o mesmo. Desta forma, o atendente, ao acessar a transação de consulta, visualiza a tela ilustrada a seguir, enquanto que o gerente visualiza a tela subseqüente. Guia de Contagem de Pontos de Função 32/39

291 A interpretação de ambas as transações quanto à contagem de um Processo Elementar para os campos Nome e CPF é a mesma já tratada no Cenário I deste tópico. Porém a interpretação quanto ao campo Saldo em Conta não é a mesma. Note que existem usuários do negócio distintos com competências também distintas dentro da aplicação. Analisando sobre a ótica do atendente, existe uma única pesquisa com duas opções de filtro, enquanto que para o gerente há também uma única pesquisa, porém com três opções de filtro disponíveis. Ou seja, analisando a demanda como um todo, dois Processos Elementares distintos podem ser identificados: uma pesquisa por Nome e CPF e outra pesquisa por Saldo em Conta. Para mais detalhes sobre a análise de transações compartilhadas por vários perfis distintos, vide tópico anterior (funções transacionais acessadas por diversos perfis de usuário) Critérios de ordenação e agrupamento A lógica de processamento reordenar ou reagrupar um conjunto de dados não causa impacto na identificação do tipo ou unicidade da função transacional. Exemplo 1: Caso existam duas funcionalidades de Listar Instituições de Ensino, sendo que a primeira ordena pelo Nome da Instituição e a segunda ordena pelo Código da Instituição, deverá ser considerado apenas um processo elementar. Exemplo 2: Por outro lado, a funcionalidade para Listar Instituições de Ensino que esteja somente em ordem alfabética e, em uma manutenção evolutiva, o cliente solicite que a lista também possa ser ordenada por UF, esta mesma funcionalidade deverá ser contada como ALTERADA. Há uma mudança em sua lógica de processamento para permitir um novo parâmetro de ordenação. As mesmas considerações acima são aplicáveis também para o caso de agrupamento de dados Histórico O histórico armazena uma fotografia dos dados em determinado momento e serve ao principal propósito de prestação de contas (a órgãos externos, a superiores ou a processos internos). Também pode ser necessário por exigência do próprio cenário de negócio. Sua existência é justificada pelo negócio, que sofre os impactos e conseqüências em caso de ausência de histórico. Deve ser considerado como registro lógico do ALI relacionado. Guia de Contagem de Pontos de Função 33/39

292 Para fazer parte do tamanho funcional, deve ser solicitado formalmente pelo cliente e deverá existir funcionalidade de consulta a tais dados Trilha de Auditoria Constitui-se de um registro de eventos históricos pré-definidos (log), destinado a ações de apuração de ocorrências, devendo identificar quem realizou a ação, quando, onde e o que foi realizado. Deve ser considerado como registro lógico do ALI relacionado. Para fazer parte do tamanho funcional, deve ser solicitada formalmente pelo cliente e deverá existir funcionalidade de consulta a tais dados Integração com o sistema de segurança do INEP A integração com o sistema de segurança pode ser realizada de quatro maneiras distintas: 1. A aplicação somente efetua leitura no sistema de segurança para autenticação do usuário e recuperação do perfil. Neste caso, devem ser contados dois AIE, sendo um para usuário/pessoa e outro para perfil. 2. A aplicação efetua a leitura no sistema de segurança apenas para autenticação do usuário. Neste caso, deve ser contado apenas um AIE (usuário/pessoa). 3. A aplicação efetua a leitura no sistema de segurança para autenticação, recuperação do perfil do usuário e registra trilha de auditoria/evento. Neste caso, devem ser contados dois AIE (usuário/pessoa e perfil) e o ALI de auditoria/evento. 4. A aplicação desenvolve suas próprias telas de logon. Neste caso, a contagem deve ser de acordo com as regras de negócio da aplicação. Poderá haver outros casos diferentes dos citados acima, cuja contagem deve ser previamente acordada com o Inep. 5 Produtividade Básica e Tipos de Contagem Como o Inep não possui base histórica de contagens de pontos de função para apoiar no cálculo de índices de produtividade, até que haja dados suficientes para tal cálculo será adotado o fator de produtividade correspondente a 13 horas por ponto de função, independente da tecnologia adotada. Para efeito do cálculo do custo final das Ordens de Serviço, tanto o desenvolvimento quanto a manutenção serão contados em, no mínimo, dois momentos distintos: Contagem estimativa necessária para embasar a abertura da Ordem de Serviço. Será realizada pela aplicação da técnica de contagem estimativa da NESMA, na qual as funções de dados são classificadas como de baixa complexidade, enquanto as funções de transação são classificadas como de média complexidade. Contagem detalhada após a homologação, para embasar o processo de pagamento. Será realizada pela aplicação da técnica de contagem documentada no Manual de Práticas de Contagem do IFPUG, acrescida, no que se aplicar, de itens tratados no presente Guia de Contagem de Pontos de Função. Guia de Contagem de Pontos de Função 34/39

293 6 Itens não mensuráveis pela Análise de Pontos de Função A Análise de Pontos de Função (APF) não mede todas as atividades relativas ao desenvolvimento e à manutenção de sistemas. Há itens que não são mensuráveis pela técnica e que não devem ser remunerados à parte, por já estarem contemplados no preço do ponto de função contratado com o fornecedor. Porém, há itens que não são medidos pela APF e não são responsabilidade ou não estão no escopo do contrato do fornecedor. Para esses casos é necessário estabelecer uma forma de remuneração do trabalho envolvido para a construção de tais itens. No Inep, as atividades não mensuráveis foram organizadas em uma tabela, que se encontra na própria planilha de contagem. Essa tabela contém os elementos/atividades não mensuráveis pela técnica da APF e um respectivo valor em pontos de função. Esse valor caracteriza uma medida de unidade de contrato, a partir da qual será possível remunerar a empresa fornecedora por atividades não passíveis de medição pela APF. Os itens não mensuráveis deverão ser apurados somente quando da realização da contagem final de pontos de função, devendo ser documentados na área apropriada da planilha de contagem. A apuração dos itens não mensuráveis é não cumulativa dentro da mesma funcionalidade: caso uma funcionalidade possua itens mensuráveis e itens não mensuráveis (uma alteração no processo elementar e uma alteração de mensagens na mesma tela, por exemplo), apenas os itens mensuráveis deverão ser apurados. 6.1 Manutenção Adaptativa A manutenção adaptativa pode incluir modificações para auxiliar atualizações de software ou de plataforma, otimização de performance e outras atividades relacionadas na manutenção. Neste tipo de manutenção não há mudanças para as funcionalidades de negócio associadas. No contexto do Inep há os seguintes tipos de serviços relacionados à Manutenção Adaptativa de Sistemas: 6.2 Manutenção adaptativa em requisitos não funcionais adequação do sistema às mudanças de ambiente operacional, compreendendo hardware e software básico, mudanças de versão, linguagem e SGBD, que não impliquem em inclusão, alteração ou exclusão de funcionalidades. Manutenção adaptativa para redesenvolvimento em outra plataforma adequação do sistema às mudanças de ambiente operacional, de modo que seja necessário reconstruir a aplicação por completo, porém sem inclusão, alteração ou exclusão de funcionalidades. Manutenção Corretiva De acordo com o IFPUG, uma manutenção corretiva não pode ser medida em pontos de função, tendo em vista que as funcionalidades com defeito pertencem a um projeto de desenvolvimento ou melhoria já executado. Para o Inep, um erro/defeito é caracterizado por funcionamento inesperado, motivado por defeitos não identificados pela equipe de testes, antes da entrega ao cliente, ou pelo próprio cliente, quando da homologação da funcionalidade. No ambiente do Inep, são encontrados dois tipos de demanda de correção: Correção de funcionalidade em garantia correção de erros em funcionalidades desenvolvidas pela empresa fornecedora e cujo período de garantia esteja vigente. Este tipo de demanda é geradora de Ordem de Serviço de garantia, a qual não é passível de medição nem de pagamento. Guia de Contagem de Pontos de Função 35/39

294 Correção de funcionalidade fora da garantia correção de erros em funcionalidades não desenvolvidas pela empresa fornecedora (legado) ou cujo período de garantia tenha expirado. Este tipo de demanda é geradora de OS de manutenção (alteração em funcionalidade para que passe a operar de acordo com a sua especificação), mensurável em pontos de função (com aplicação do mesmo redutor para pagamento relacionado a funções alteradas). Caso a manutenção corretiva fora da garantia não esteja associada a alguma funcionalidade específica, abrangendo características gerais da aplicação (ou requisitos não funcionais), esta será tratada conforme a tabela de Itens Não Mensuráveis (INM), apresentada mais adiante. Não serão considerados como defeitos aqueles problemas reportados pelo cliente e que, após verificação pelo Gerente de Projetos do Inep, sejam apurados como sendo mudanças nos requisitos homologados. Esses casos serão tratados como alteração de funcionalidade e serão incluídos no backlog do produto, para execução em momento oportuno. 6.3 Manutenção Cosmética Esta manutenção é caracterizada por alterações referentes exclusivamente aos leiautes de telas, mudança de posição de campos em telas, relatórios ou leiaute de arquivos, divisão de telas e/ou relatórios, sem que haja alteração em elementos de dados, arquivos referenciados ou informações de controle. 6.4 Dados de Código Conforme estabelecido pelo IFPUG, dados de código não devem ser reconhecidos como Arquivos Lógicos durante a medição, assim como não devem participar da medição as transações que trabalhem exclusivamente com este tipo de dado. Com base neste entendimento, em um projeto de desenvolvimento, a implementação de tabelas que representam dados de código, bem como a construção de transações para operar sobre estes dados não deverá afetar a contagem de pontos de função, nem ser remunerada separadamente. O preço por Ponto de Função estabelecido no contrato leva em consideração os requisitos técnicos e de qualidade que o cliente espera do serviço. O mesmo vale para os projetos de melhoria que, em função da manutenção, gerem/alterem dados de código sobre as funcionalidades alteradas. É importante enfatizar que, por serem consideradas itens não mensuráveis, as tabelas de dados de código não são ALIs ou AIEs da aplicação e, portanto, não podem ser consideradas arquivos referenciados nos processos elementares contados no tamanho funcional da aplicação. 6.5 Mensagens Contemplam as manutenções associadas a alterações em mensagens de retorno ao usuário, desde que não sejam recuperadas de ALIs ou AIEs. 6.6 Parâmetros de Processamento Contemplam as manutenções associadas a alterações dos valores de parâmetros, sem que a lógica de processamento tenha sido alterada. Guia de Contagem de Pontos de Função 36/39

295 6.7 Forma de Ordenação Contempla a mudança de ordenação de uma consulta ou relatório, sem que haja mudança na lógica de processamento. 6.8 Tabelas não mantidas pelo Usuário Contemplam tabelas que não são consideradas ALIs, AIEs ou registros lógicos, e que não são mantidas pelo usuário. Por exemplo: tabelas temporárias, code tables não mantidas pelo usuário, tabelas de log não reconhecidas pelo usuário, dados de controle não reconhecidos pelo usuário ou tabelas utilizadas apenas para auxiliar na implementação tecnológica (sumários ou resumos). 6.9 Programas Auxiliares Também conhecidos como apurações especiais, contemplam dois conceitos: Geração de relatórios e/ou arquivos, a pedido do cliente, para identificar determinados registros na base de dados para posterior correção, ou geração de arquivos que serão utilizados uma única vez para popular massa de teste. Construção de rotinas auxiliares desenvolvidas pelos técnicos para alterar campos em determinados registros de tabelas do sistema, a pedido do cliente (convém ressaltar que não se trata de um caso de defeito, mas de uma alteração pontual, geralmente em registros apontados pelo cliente) Páginas Estáticas Contemplam a inclusão, alteração ou exclusão de páginas que não possuem dados do negócio (tipos de dados) que atravessem a fronteira da aplicação. As páginas estáticas serão tratadas com base no item 4.10 (Manutenção em Páginas Estáticas de Intranet, Internet ou Portal) do Roteiro de Métricas de Software do SISP, disponível em cada página estática será considerada como uma consulta externa de complexidade simples Tabela de Itens Não Mensuráveis (INMs) Conforme preconizado pela Análise de Pontos de Função, nem todos os tipos de solicitações podem ser medidas em Pontos de Função, uma vez que esta tem o foco única e exclusivamente sobre os requisitos funcionais da aplicação, sem analisar como uma aplicação é construída, e levando em consideração apenas o que ela disponibiliza ao usuário. No entanto, o usuário constantemente encaminha solicitações com requisitos não-funcionais, que não interferem no negócio da aplicação, porém são necessárias e devem ser atendidas. Por exemplo: a abertura de uma demanda para alterar a interface gráfica da aplicação (estrutura do layout, cores, imagens, botões, etc). A fim de enquadrar estes tipos de demanda, será adotada a tabela de itens não mensuráveis detalhada a seguir: INM Manutenção adaptativa em requisitos não funcionais Guia de Contagem de Pontos de Função Redutor 50% Descrição O Inep pagará 50% do valor dos pontos de função apurados para as funções afetadas pela manutenção. 37/39

296 INM Redutor Descrição Manutenção adaptativa para redesenvolvimento em outra plataforma 100% O Inep pagará 100% do valor dos pontos de função apurados para as funções afetadas pela manutenção. Manutenção corretiva fora da garantia 60% O Inep pagará 60% do valor dos pontos de função apurados para as funções afetadas pela manutenção. Manutenção cosmética 10% O Inep pagará 10% do valor das funções de transação afetadas pela manutenção. Code table 20% O Inep pagará 20% do valor das funções de dados e/ou de transação, caso fossem mensuráveis no tamanho funcional do projeto. Menus e folhas de estilo 0% Apesar de serem manutenções cosméticas, alterações referentes a ajustes em menus de navegação e suas respectivas folhas de estilo não estão enquadradas neste item, uma vez que a maior parte dos itens de menu estão contemplados na chamada de funções de transação mensuráveis, ou de páginas estáticas, descritas adiante nesta tabela. Mensagens 1% O Inep pagará 1% do valor dos pontos de função do processo elementar atingido (por grupo de mensagens). Parâmetros de processamento 5% O Inep pagará 5% do valor dos pontos de função do processo elementar alterado. Forma de ordenação 5% O Inep pagará 5% do valor dos pontos de função do processo elementar alterado. Tabelas não mantidas pelo usuário 0% Dados deste tipo não serão considerados na contagem de pontos de função. Programas auxiliares 20% O Inep pagará 20% do valor dos pontos de função do programa auxiliar construído. Páginas estáticas 50% O Inep pagará 50% do valor dos pontos de função de uma consulta externa simples por página estática incluída, alterada ou excluída. 7 Medição de projetos/serviços cancelados A Metodologia de Gestão e Desenvolvimento de Sistemas do INEP prevê todas as fases necessárias à produção e entrega de software. No entanto, poderá haver situações em que, por razões adversas, um projeto ou serviço de manutenção tenha seu desenvolvimento interrompido, desencadeando a necessidade de apuração da quantidade de esforço até então dispendido, para fins de pagamento à prestadora. Para esses casos, deverá ser realizada a contagem detalhada de todos os itens já implementados em forma de código-fonte e que atendam à definição de pronto acordada com o cliente, para posterior validação e aceite pelo Inep. Guia de Contagem de Pontos de Função 38/39

297 Referências IFPUG. Counting practices manual version 4.2.1, Princeton Junction, VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme Siqueira, MACHADO, Renato. Análise de pontos de função: medição, estimativas e gerenciamento de projetos de software (cartão de referência). São Paulo: Érica, Contagem antecipada de pontos de função (NESMA early FPA counting). Disponível em Acesso em 13/10/2009. Fundo Nacional de Desenvolvimento da Educação. Guia de Contagem do FNDE, v.2.4. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Roteiro de métricas de software do SISP, v.1.0. Guia de Contagem de Pontos de Função 39/39

298 INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA - INEP DIRETORIA DE TECNOLOGIA E DISSEMINAÇÃO DE INFORMAÇÕES EDUCACIONAIS - DTDIE COORDENAÇÃO GERAL DE INFRAESTRUTURA E SERVIÇOS - CGIS GUIA DE ETL Brasília / 2010 Histórico de Revisão Guia de ETL 1

299 Versão Dt. Data Responsável Motivação /06/2010 Débora Formiga Criação e documentação /08/2010 Débora Formiga Adicionar informações de metadados de tratamentos de erros e de dimensão de auditoria /08/2010 Daniel Julião Adição do fluxo de atividades e descrição das mesmas. Guia de ETL 2

300 1 Introdução Este documento tem o objetivo de apresentar regras específicas e orientações gerais (boas práticas) dos processos ETL, além de definir um padrão de nomenclatura para os objetos a serem utilizados nos processos ETL e a documentação necessária para manter a qualidade dos metadados. 2 Informações Relevantes 2.1 Staging Area A Staging Area é uma área de armazenamento e conjunto de processos que limpam, transformam, combinam, retiram duplicidades, armazenam e preparam dados de origem para serem usados no data warehouse. As tabelas a serem criadas na Staging Area devem utilizar a mesma nomenclatura adotada pela(s) fonte(s) de dados, acrescentando o campo NU_ANO, numérico de 4 (quatro) posições, quando for o caso. 3 ETL No ambiente de data warehouse, os dados são inicialmente extraídos de sistemas operacionais e de fontes externas, posteriormente integrados e transformados (limpos, eliminados, combinados, validados, consolidados, agregados e sumarizados), antes de serem carregados no data warehouse. Finalmente, os usuários acessam o DW através de ferramentas de front-end ou aplicações submetendo suas consultas, de modo a obterem informações que permitam a tomada de decisões. Um DW contém dados sumarizados, históricos e detalhados para suportar a tomada de decisões táticas e estratégicas. A figura 1 apresenta o ambiente data warehouse, mostrando o fluxo realizado até a disponibilização dos dados aos usuários. Guia de ETL 3

301 Figura 1: Ambiente Data Warehouse. 3.1 Extração A extração é o primeiro passo na obtenção de dados para o ambiente do DW. Significa basicamente ler e entender as fontes de dados e copiar as partes necessárias para a área de transformação de dados, a fim de serem trabalhadas posteriormente. Na grande maioria dos DW, os dados provêm de várias fontes diferentes e independentes, podendo ser essas fontes as bases de dados dos sistemas transacionais, planilhas excel, etc. Freqüentemente, o grande desafio é determinar quais dados extrair e que tipos de filtros aplicar, essa atividade é uma das que mais consomem tempo na construção do DW. A extração pode ser conduzida através da construção de programas cujo código é executado sobre um sistema fonte de modo a gerar arquivos com os dados desejados. Outra opção é utilizar ferramentas de extração específicas que geram código próprio, interno à ferramenta, executado sobre o sistema fonte, de forma a obter os dados necessários, de preferência dentro de arquivos de formato não proprietário, como, por exemplo, arquivos texto. 3.2 Transformação Após a extração dos dados dos sistemas fontes, são realizadas uma série de atividades sobre esses dados de modo a convertê-los em formato adequado para carga Guia de ETL 4

O GOVERNADOR DO ESTADO DO RIO GRANDE DO SUL, no uso da atribuição que lhe confere o art. 82, incisos V e VII, da Constituição do Estado,

O GOVERNADOR DO ESTADO DO RIO GRANDE DO SUL, no uso da atribuição que lhe confere o art. 82, incisos V e VII, da Constituição do Estado, DECRETO N 42.434, DE 09 DE SETEMBRO DE 2003, DOERS. Regulamenta, no âmbito do Estado do Rio Grande do Sul, a modalidade de licitação denominada pregão, por meio eletrônico, para a aquisição de bens e serviços

Leia mais

MUNICÍPIO DE SENGÉS CNPJ/MF 76.911.676/0001-07 TRAVESSA SENADOR SOUZA NAVES N. 95 SENGÉS PARANÁ

MUNICÍPIO DE SENGÉS CNPJ/MF 76.911.676/0001-07 TRAVESSA SENADOR SOUZA NAVES N. 95 SENGÉS PARANÁ DECRETO Nº 600/2014 Súmula:- Regulamenta a aquisição de Bens Permanentes, de Consumo e Serviços destinados a Administração Direta, Indireta e Fundacional do Município de Sengés, através de Pregão, tendo

Leia mais

ESCLARECIMENTOS. Em virtude do exposto, segue o Anexo A, com os itens mencionados, que para todos os efeitos ficam incorporados ao edital publicado.

ESCLARECIMENTOS. Em virtude do exposto, segue o Anexo A, com os itens mencionados, que para todos os efeitos ficam incorporados ao edital publicado. ESCLARECIMENTOS Em curso nesta Autarquia a licitação nº 0453/13, Processo nº 0363/13, que almeja a contratação de pessoa jurídica para prestação de serviços de medicina e segurança do trabalho. Foi recebido

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N. º 53/2008 DTDIE / INEP PROCESSO N.º 23036.003304/2008-82

EDITAL DO PREGÃO ELETRÔNICO N. º 53/2008 DTDIE / INEP PROCESSO N.º 23036.003304/2008-82 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS Esplanada

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 31/2008 DTDIE/ INEP PROCESSO N.º 23036.001541/2008-17

EDITAL DO PREGÃO ELETRÔNICO N.º 31/2008 DTDIE/ INEP PROCESSO N.º 23036.001541/2008-17 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS Esplanada

Leia mais

DECRETO Nº. 6.204, DE 5 DE SETEMBRO DE 2007 DOU 06.09.2007

DECRETO Nº. 6.204, DE 5 DE SETEMBRO DE 2007 DOU 06.09.2007 DECRETO Nº. 6.204, DE 5 DE SETEMBRO DE 2007 DOU 06.09.2007 Regulamenta o tratamento favorecido, diferenciado e simplificado para as microempresas e empresas de pequeno porte nas contratações públicas de

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 22/2012 PROCESSO N.º 23036.000836/2012-44

EDITAL DO PREGÃO ELETRÔNICO N.º 22/2012 PROCESSO N.º 23036.000836/2012-44 , MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS

Leia mais

EDITAL ALTERADO DO PREGÃO ELETRÔNICO N.º 11/2010

EDITAL ALTERADO DO PREGÃO ELETRÔNICO N.º 11/2010 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 29/2012 PROCESSO N.º 23036.001430/2012-89

EDITAL DO PREGÃO ELETRÔNICO N.º 29/2012 PROCESSO N.º 23036.001430/2012-89 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 26/2010

EDITAL DO PREGÃO ELETRÔNICO N.º 26/2010 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 25/2011 REGISTRO DE PREÇOS PROCESSO N.º 23036.001403/2011-25

EDITAL DO PREGÃO ELETRÔNICO N.º 25/2011 REGISTRO DE PREÇOS PROCESSO N.º 23036.001403/2011-25 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

MINISTÉRIO DA FAZENDA SUPERINTENDÊNCIA DE SEGUROS PRIVADOS PROCESSO SUSEP 15414.003162/2008-71 PREGÃO ELETRÔNICO Nº 04/2009

MINISTÉRIO DA FAZENDA SUPERINTENDÊNCIA DE SEGUROS PRIVADOS PROCESSO SUSEP 15414.003162/2008-71 PREGÃO ELETRÔNICO Nº 04/2009 A Superintendência de Seguros Privados - SUSEP realizará, às 15 horas do dia 16 de julho de 2009, licitação na modalidade PREGÃO ELETRÔNICO, tipo MENOR PREÇO, conforme autorização da Senhora Chefe do DEAFI,

Leia mais

CARTA CONVITE Nº 002/2010

CARTA CONVITE Nº 002/2010 IMPORTANTE: PARA PARTICIPAR DA LICITAÇÃO O INTERESSADO DEVERÁ RETIRAR O EDITAL SOB PROTOCOLO COM ATÉ 24 HORAS DE ANTECEDENCIA DO CERTAME NA SEDE DO CONSELHO SITUADO À RUA PAMPLONA, 1200 JD PAULISTA CEP:

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 30/2012 PROCESSO N.º 23036.000783/2012-61

EDITAL DO PREGÃO ELETRÔNICO N.º 30/2012 PROCESSO N.º 23036.000783/2012-61 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

PREGÃO ELETRÔNICO Nº002/2011/CISMEPA REGISTRO DE PREÇOS

PREGÃO ELETRÔNICO Nº002/2011/CISMEPA REGISTRO DE PREÇOS 1 PREGÃO ELETRÔNICO Nº002/2011/CISMEPA REGISTRO DE PREÇOS O CONSORCIO INTERMUNICIPAL DE SAUDE DO MEDIO PARAIBA, mediante o Pregoeiro Flávio Macharet Barbosa, designado pela Portaria nº 004/2011, de junho

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 14/2010. Registro de Preços PROCESSO N.º 23036.000965/2010-71

EDITAL DO PREGÃO ELETRÔNICO N.º 14/2010. Registro de Preços PROCESSO N.º 23036.000965/2010-71 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

1.1 O recebimento dos envelopes dar-se-á até às 14:00h do dia 09 de março de 2010, pela Comissão Permanente de Licitação, no endereço acima citado.

1.1 O recebimento dos envelopes dar-se-á até às 14:00h do dia 09 de março de 2010, pela Comissão Permanente de Licitação, no endereço acima citado. EDITAL DE CARTA CONVITE N 02/2010 CRM-PR OBJETIVANDO A CONTRATAÇÃO DE SERVIÇOS DE ASSESSORIA PARA O DESENVOLVIMENTO E SUPERVISÃO DE PROJETO DE TELEMEDICINA, VIDEOCONFERÊNCIA E EDUCAÇÃO CONTINUADA PARA

Leia mais

ESTADO DO ACRE DECRETO Nº 5.966 DE 30 DE DEZEMBRO DE 2010

ESTADO DO ACRE DECRETO Nº 5.966 DE 30 DE DEZEMBRO DE 2010 Regulamenta o tratamento favorecido, diferenciado e simplificado para as microempresas, empresas de pequeno porte e equiparadas nas contratações de bens, prestação de serviços e execução de obras, no âmbito

Leia mais

PERGUNTAS E RESPOSTAS

PERGUNTAS E RESPOSTAS MICRO E PEQUENAS EMPRESAS PERGUNTAS E RESPOSTAS 1. O microempreendedor individual pode participar de compras públicas? Sim, o Microempreendedor (MEI), pode participar de licitações. A Administração deverá

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 27/2011 DGP/INEP

EDITAL DO PREGÃO ELETRÔNICO N.º 27/2011 DGP/INEP MINISTÉRIO DA EDUCAÇÃO INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS Quadra 701, Bloco M, Asa Sul, Ed. Sede do Inep, 2º Andar. CEP: 70340-909

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 01/2011

EDITAL DO PREGÃO ELETRÔNICO N.º 01/2011 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 22/2011

EDITAL DO PREGÃO ELETRÔNICO N.º 22/2011 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 05/2010 DTDIE/INEP PROCESSO N.º 23036.002985/2009-42

EDITAL DO PREGÃO ELETRÔNICO N.º 05/2010 DTDIE/INEP PROCESSO N.º 23036.002985/2009-42 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

EDITAL ALTERADO PREGÃO ELETRÔNICO N.º 38/2008. Registro de Preços

EDITAL ALTERADO PREGÃO ELETRÔNICO N.º 38/2008. Registro de Preços MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA-INEP COORDENAÇÃO-GERAL DE RECURSOS LOGÍSTICOS, AQUISIÇÕES E CONVÊNIOS Esplanada dos Ministérios Bloco L Anexo

Leia mais

CARTA CONVITE Nº 023/2009

CARTA CONVITE Nº 023/2009 IMPORTANTE: PARA PARTICIPAR DA LICITAÇÃO O INTERESSADO DEVERÁ RETIRAR O EDITAL SOB PROTOCOLO COM ATÉ 24 HORAS DE ANTECEDENCIA DO CERTAME NA SEDE DO CONSELHO SITUADO À RUA PAMPLONA, 1200 JD PAULISTA CEP:

Leia mais

O GOVERNADOR DO ESTADO DO AMAZONAS, no exercício da competência que lhe confere o art. 54, inciso IV, da Constituição Estadual, e

O GOVERNADOR DO ESTADO DO AMAZONAS, no exercício da competência que lhe confere o art. 54, inciso IV, da Constituição Estadual, e DECRETO No. 24.818 de 27 JANEIRO DE 2.005 Regulamenta a realização de pregão por meio da utilização de recursos de tecnologia da informação, denominado pregão eletrônico, para a aquisição de bens e serviços

Leia mais

DECRETO N 001 A / 2015 De 02 de janeiro de 2015.

DECRETO N 001 A / 2015 De 02 de janeiro de 2015. DECRETO N 001 A / 2015 De 02 de janeiro de 2015. EMENTA: Regulamenta o Sistema de Registro de Preços SRP previsto no art. 15 da Lei nº 8.666/93, no âmbito do Município de Central Bahia. O PREFEITO DO MUNICÍPIO

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 21/2011 REGISTRO DE PREÇOS PROCESSO N.º 23036.001404/2011-70

EDITAL DO PREGÃO ELETRÔNICO N.º 21/2011 REGISTRO DE PREÇOS PROCESSO N.º 23036.001404/2011-70 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

Presidência da República Casa Civil Subchefia para Assuntos Jurídicos

Presidência da República Casa Civil Subchefia para Assuntos Jurídicos 1 de 7 07/10/2015 10:08 Presidência da República Casa Civil Subchefia para Assuntos Jurídicos DECRETO Nº 8.538, DE 6 DE OUTUBRO DE 2015 Vigência Regulamenta o tratamento favorecido, diferenciado e simplificado

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 29/2008 DTDIE/ INEP PROCESSO N.º 23036.001804/2008-80

EDITAL DO PREGÃO ELETRÔNICO N.º 29/2008 DTDIE/ INEP PROCESSO N.º 23036.001804/2008-80 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS Esplanada

Leia mais

COMPANHIA DE SANEAMENTO DE MINAS GERAIS COPASA MG CNPJ/MF 17.281.106/0001 03 Rua Mar de Espanha, 453 / Sto. Antônio Belo Horizonte (MG)

COMPANHIA DE SANEAMENTO DE MINAS GERAIS COPASA MG CNPJ/MF 17.281.106/0001 03 Rua Mar de Espanha, 453 / Sto. Antônio Belo Horizonte (MG) COMPANHIA DE SANEAMENTO DE MINAS GERAIS COPASA MG CNPJ/MF 17.281.106/0001 03 Rua Mar de Espanha, 453 / Sto. Antônio Belo Horizonte (MG) NORMAS DE CREDENCIAMENTO PARA INSTITUIÇÕES BANCÁRIAS 1. DA FINALIDADE

Leia mais

Decreto nº 8.538, de 6 de outubro de 2015 Decreto nº 6.204, de 5 de setembro de 2007

Decreto nº 8.538, de 6 de outubro de 2015 Decreto nº 6.204, de 5 de setembro de 2007 DECRETO 8.538/2015 COMPARATIVO COM DECRETO 6.204/2007 Outubro/2015 Importante: Pontos acrescidos estão destacados em verde. Pontos suprimidos estão destacados em vermelho. Decreto nº 8.538, de 6 de outubro

Leia mais

CLÁUSULA SEGUNDA - DA VINCULAÇÃO AO EDITAL

CLÁUSULA SEGUNDA - DA VINCULAÇÃO AO EDITAL PROCESSO Nº 01550.000345/2009-46. PREGÃO Nº 26/2009. ATA DE REGISTRO DE PREÇOS Nº 1/2010. A FUNDAÇÃO CASA DE RUI BARBOSA, pessoa jurídica de direito público vinculada a Ministério da Cultura, com sede

Leia mais

ESTADO DO RIO GRANDE DO SUL PREFEITURA MUNICIPAL DE SANTANA DA BOA VISTA TERRA DE LUTA E FÉ - DOE ORGÃOS, DOE SANGUE:SALVE VIDAS

ESTADO DO RIO GRANDE DO SUL PREFEITURA MUNICIPAL DE SANTANA DA BOA VISTA TERRA DE LUTA E FÉ - DOE ORGÃOS, DOE SANGUE:SALVE VIDAS EDITAL DE CARTA CONVITE 027/2015 A PREFEITA MUNICIPAL DE SANTANA DA BOA VISTA, torna público, para conhecimento dos interessados, que no dia 20 DE NOVEMBRO DE 2015, às 10 horas, reunirse-á a Comissão Permanente

Leia mais

CARTA CONVITE Nº 028/2009 M I N U T A

CARTA CONVITE Nº 028/2009 M I N U T A IMPORTANTE : PARA PARTICIPAR DA LICITAÇÃO O INTERESSADO DEVERÁ RETIRAR O EDITAL SOB PROTOCOLO COM ATÉ 24 HORAS DE ANTECEDÊNCIA DO CERTAME NA SEDE DO CONSELHO SITUADO À RUA PAMPLONA, 1200 JARDIM PAULISTA

Leia mais

INSCRIÇÃO OU RENOVAÇÃO CADASTRAL

INSCRIÇÃO OU RENOVAÇÃO CADASTRAL INSCRIÇÃO OU RENOVAÇÃO CADASTRAL 1. DA ENTREGA DA DOCUMENTAÇÃO 1.1. Os interessados em se inscrever e/ou renovar o Registro Cadastral junto ao GRB deverão encaminhar a documentação a seguir estabelecida,

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N. º 13/2009 DTDIE/ INEP PROCESSO N.º 23036.000546/2009-03

EDITAL DO PREGÃO ELETRÔNICO N. º 13/2009 DTDIE/ INEP PROCESSO N.º 23036.000546/2009-03 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

Edital de Credenciamento 003/2012

Edital de Credenciamento 003/2012 1/5 Edital de Credenciamento 003/2012 1 DO OBJETO: 1.1. O presente Termo tem por objetivo o credenciamento de Instituições Financeiras autorizadas a funcionar pelo Banco Central do Brasil, para prestação

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 22 /2009. Registro de Preços PROCESSO N.º 23036.001632/2009-25

EDITAL DO PREGÃO ELETRÔNICO N.º 22 /2009. Registro de Preços PROCESSO N.º 23036.001632/2009-25 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

CONSELHO FEDERAL DE NUTRICIONISTAS CONSELHO REGIONAL DE NUTRICIONISTAS - 3ª Região (SP, MS)

CONSELHO FEDERAL DE NUTRICIONISTAS CONSELHO REGIONAL DE NUTRICIONISTAS - 3ª Região (SP, MS) CARTA CONVITE Nº: 008/2013. São Paulo, 04 de junho de 2.013. Processo n.º 042-05/2013 Tipo: MENOR PREÇO Firma: A/C: E-mail: Convidamos a referida empresa a apresentar proposta para atendimento do objeto

Leia mais

EDITAL OBJETO: CABO GIGALAN CATEGORIA 6 U/UTP 23AWGX4PARES - VERMELHO EM CAIXA DE 305 METROS, CONFORME ESPECIFICAÇÃO TECNICA Nº 036/2009.

EDITAL OBJETO: CABO GIGALAN CATEGORIA 6 U/UTP 23AWGX4PARES - VERMELHO EM CAIXA DE 305 METROS, CONFORME ESPECIFICAÇÃO TECNICA Nº 036/2009. EDITAL A SÃO PAULO TRANSPORTE S.A. SPTrans, inscrita no CNPJ-MF sob o n.º 60.498.417/0001-58, comunica que se encontra aberta a licitação, EXCLUSIVAMENTE para participação de microempresas e empresas de

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 10/2011 PROCESSO N.º 23036.000846/2011-07

EDITAL DO PREGÃO ELETRÔNICO N.º 10/2011 PROCESSO N.º 23036.000846/2011-07 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

I - LOCAL DE ENTREGA DOS ENVELOPES:

I - LOCAL DE ENTREGA DOS ENVELOPES: EDITAL de LICITAÇÃO MODALIDADE: CARTA CONVITE N.º 17/2013 Data da abertura dos envelopes: Dia: 25/10/2013 Horário: 13:00 horas Data limite para entrega dos envelopes: Dia: 25/10/2013 Horário: 13:00 horas

Leia mais

MINUTA EDITAL DO PREGÃO ELETRÔNICO N.º 10/2010 DTDIE/INEP PROCESSO N.º 23036.000364/2010-68

MINUTA EDITAL DO PREGÃO ELETRÔNICO N.º 10/2010 DTDIE/INEP PROCESSO N.º 23036.000364/2010-68 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

CARTA CONVITE Nº 005/2008 M I N U T A

CARTA CONVITE Nº 005/2008 M I N U T A IMPORTANTE : PARA PARTICIPAR DA LICITAÇÃO O INTERESSADO DEVERÁ RETIRAR O EDITAL SOB PROTOCOLO COM ATÉ 24 HORAS DE ANTECEDÊNCIA DO CERTAME NA SEDE DO CONSELHO SITUADO À RUA PAMPLONA, 1200 JD PAULISTA CEP:

Leia mais

Dispõe sobre a Cotação Eletrônica de Preços no Estado do Rio Grande do Sul.

Dispõe sobre a Cotação Eletrônica de Preços no Estado do Rio Grande do Sul. LEI Nº 13.179, DE 10 DE JUNHO DE 2009 Business Online Comunicação de Dados Dispõe sobre a Cotação Eletrônica de Preços no Estado do Rio Grande do Sul. A GOVERNADORA DO ESTADO DO RIO GRANDE DO SUL. Faço

Leia mais

CONTAGEM DO PRAZO LEGAL

CONTAGEM DO PRAZO LEGAL Curso de Licitação. Pregão Presencial e Pregão Eletrônico Professor: Antônio Noronha Os 3 Caminhos Possíveis para Aquisição/ Serviços, etc... Licitação; Dispensa de Licitação; Inexigibilidade de Licitação.

Leia mais

GOVERNO DO ESTADO DO CEARÁ SECRETARIA DA EDUCAÇÃO EEEP RITA MATOS LUNA JUCÁS CEARÁ

GOVERNO DO ESTADO DO CEARÁ SECRETARIA DA EDUCAÇÃO EEEP RITA MATOS LUNA JUCÁS CEARÁ Convite N. 004/2015 Natureza da Despesa/ OBJETIVO: Fonte do Recurso Contratação de Serviço de INSTALAÇÃO DE SERVIÇO DE LINK DE INTERNET - 5MB Dotação Orçamentária Data da Emissão 22/06/2015 Data da Licitação

Leia mais

PROCESSO 005/2010 EDITAL DE CREDENCIAMENTO 001/2010

PROCESSO 005/2010 EDITAL DE CREDENCIAMENTO 001/2010 INSTITUTO DE PREVIDÊNCIA DOS SERVIDORES DO MUNICÍPIO DE SÃO SEBASTIÃO DO PARAÍSO, Regime Próprio de Previdência Social dos Servidores Públicos Municipais de São Sebastião do Paraíso, autarquia municipal,

Leia mais

Considerando a necessidade de se buscar a redução de custos, em função do aumento da competitividade; e

Considerando a necessidade de se buscar a redução de custos, em função do aumento da competitividade; e Página 1 de 5 PORTARIA Nº 306, DE 13 DE DEZEMBRO DE 2001 MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO GABINETE DO MINISTRO O MINISTRO DE ESTADO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO, no uso das atribuições

Leia mais

ATO CONVOCATÓRIO 002 2013. OBJETO: Credenciamento de Consultores

ATO CONVOCATÓRIO 002 2013. OBJETO: Credenciamento de Consultores ATO CONVOCATÓRIO 002 2013 OBJETO: Credenciamento de Consultores O INSTITUTO QUALIDADE MINAS, pessoa jurídica de Direito privado sem fins lucrativos, qualificada como Organização da Sociedade Civil de Interesse

Leia mais

Regulamenta o Sistema de Registro de Preços previsto no art. 15 da Lei nº 8.666, de 21 de junho de 1993.

Regulamenta o Sistema de Registro de Preços previsto no art. 15 da Lei nº 8.666, de 21 de junho de 1993. DECRETO N.º 7.892, DE 23 DE JANEIRO DE 2013. Regulamenta o Sistema de Registro de Preços previsto no art. 15 da Lei nº 8.666, de 21 de junho de 1993. A PRESIDENTA DA REPÚBLICA, no uso da atribuição que

Leia mais

PREFEITURA MUNICIPAL DE FRANCA Secretaria de Planejamento e Gestão Econômica Divisão de Licitações e Compras Convite nº 081/2007 Fls.

PREFEITURA MUNICIPAL DE FRANCA Secretaria de Planejamento e Gestão Econômica Divisão de Licitações e Compras Convite nº 081/2007 Fls. Convite nº 081/2007 Fls. 1 CARTA CONVITE Processo nº 11784/05 Convite nº 081/2007 Entrega Envelopes até o dia: 15 de junho de 2007, às 14h00. Abertura Envelopes dia: 15 de junho de 2007, às 14h30. A COMISSÃO

Leia mais

PROTOCOLO 23064.008432/2013-42 MINUTA DE EDITAL PREGÃO ELETRÔNICO Nº 122/2013

PROTOCOLO 23064.008432/2013-42 MINUTA DE EDITAL PREGÃO ELETRÔNICO Nº 122/2013 MINISTÉRIO DA EDUCAÇÃO UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ PROTOCOLO 23064.008432/2013-42 MINUTA DE EDITAL PREGÃO ELETRÔNICO Nº 122/2013 A UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Campus Curitiba,

Leia mais

ESTADO DO RIO GRANDE DO SUL ASSEMBLEIA LEGISLATIVA Gabinete de Consultoria Legislativa

ESTADO DO RIO GRANDE DO SUL ASSEMBLEIA LEGISLATIVA Gabinete de Consultoria Legislativa ESTADO DO RIO GRANDE DO SUL ASSEMBLEIA LEGISLATIVA Gabinete de Consultoria Legislativa LEI Nº 13.179, DE 10 DE JUNHO DE 2009. (publicada no DOE nº 109, de 12 de junho de 2009) Dispõe sobre a Cotação Eletrônica

Leia mais

ATA DE REGISTRO DE PREÇOS PREGÃO Nº.../20... PROCESSO Nº 1.00.000.003689/2013-00 VALIDADE: 12 (DOZE) MESES ATA Nº.../20...

ATA DE REGISTRO DE PREÇOS PREGÃO Nº.../20... PROCESSO Nº 1.00.000.003689/2013-00 VALIDADE: 12 (DOZE) MESES ATA Nº.../20... ATA DE REGISTRO DE PREÇOS PREGÃO Nº.../20... PROCESSO Nº 1.00.000.003689/2013-00 VALIDADE: 12 (DOZE) MESES ATA Nº.../20... Ao...do dia do mês de... do ano de 20..., na PROCURADORIA GERAL DA REPÚBLICA PGR,

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 18 /2009. Registro de Preços PROCESSO N.º 23036.001055/2009-71

EDITAL DO PREGÃO ELETRÔNICO N.º 18 /2009. Registro de Preços PROCESSO N.º 23036.001055/2009-71 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

TERMO DE REFERÊNCIA 1. DO OBJETO

TERMO DE REFERÊNCIA 1. DO OBJETO TERMO DE REFERÊNCIA 1. DO OBJETO 1.1 Contratação de serviço de fornecimento de assinatura de jornais impressos e revistas, assim como acesso às matérias on line dos respectivos jornais e revistas para

Leia mais

DISPENSA DE LICITAÇÃO ELETRÔNICA Nº. 18319

DISPENSA DE LICITAÇÃO ELETRÔNICA Nº. 18319 Processo nº. 200910267000429 Data da Realização: 09/12/2009 Horário: 09:00 horas Local: www.comprasnet.go.gov.br DISPENSA DE LICITAÇÃO ELETRÔNICA Nº. 18319 A FUNDAÇÃO DE AMPARO À PESQUISA DO ESTADO DE

Leia mais

CONSELHO REGIONAL DE BIOMEDICINA 1ª REGIÃO

CONSELHO REGIONAL DE BIOMEDICINA 1ª REGIÃO 1 CARTA CONVITE n.º 001/2011 São Paulo, 20 de outubro de 2011. O CONSELHO REGIONAL DE BIOMEDICINA - 1ª REGIÃO, nos termos da autorização constante no Processo Administrativo em epígrafe, vem, por intermédio

Leia mais

O que é o Cadastro Unificado de Fornecedores do Estado - CADFOR? Como posso emitir meu Certificado de Registro Cadastral CRC homologado?

O que é o Cadastro Unificado de Fornecedores do Estado - CADFOR? Como posso emitir meu Certificado de Registro Cadastral CRC homologado? O que é o Cadastro Unificado de Fornecedores do Estado - CADFOR? O Cadastro Unificado de Fornecedores do Estado CADFOR é o registro cadastral de interessados em fornecer produtos, serviço e/ou obras para

Leia mais

RESUMO DO DECRETO MUNICIPAL Nº 49.511/08 - SP

RESUMO DO DECRETO MUNICIPAL Nº 49.511/08 - SP RESUMO DO DECRETO MUNICIPAL Nº 49.511/08 - SP O Decreto Municipal Nº 49.511/08 regulamenta, no âmbito do Município de São Paulo, as normas definidas na Lei Complementar nº 123/06, que criou o Estatuto

Leia mais

PROCESSO SELETIVO Nº 004/2012

PROCESSO SELETIVO Nº 004/2012 PROCESSO SELETIVO Nº 004/2012 O Instituto de Gestão e Humanização IGH, torna público para conhecimento dos interessados, que fará realizar Processo Seletivo objetivando a contratação de serviços de Coleta,

Leia mais

Tribunal Regional Eleitoral do Amapá COORDENADORIA DE MATERIAL E PATRIMÔNIO

Tribunal Regional Eleitoral do Amapá COORDENADORIA DE MATERIAL E PATRIMÔNIO ATA DE REGISTRO DE PREÇOS n.º 25 /2014 PROCESSO n.º 62/2013 (Protocolo nº 6.007). PREGÃO ELETRÔNICO n.º 49/2013 VALIDADE: 12 (doze) meses Aos quatorze dias do mês de abril do ano de dois mil e quatorze,

Leia mais

COLETA DE PREÇOS nº 07/2013

COLETA DE PREÇOS nº 07/2013 COLETA DE PREÇOS nº 07/2013 1. PREÂMBULO 1.1. A ASSOCIAÇÃO MUSEU AFRO BRASIL, torna pública a realização de Seleção de Fornecedores na modalidade Coleta de Preços, pelo critério de menor preço, objetivando

Leia mais

1.2. Classificação da empresa segundo seu porte. 1.3.1. Quando deve ser comprovado o porte da empresa. 1.3.2. Documentação para comprovação de porte

1.2. Classificação da empresa segundo seu porte. 1.3.1. Quando deve ser comprovado o porte da empresa. 1.3.2. Documentação para comprovação de porte Atualizado: 15 / 06 / 2015 - FAQ AI 1. Porte 1.1. Porte da empresa 1.1.1. Faturamento Bruto Anual 1.2. Classificação da empresa segundo seu porte 1.3. Comprovação de porte 1.3.1. Quando deve ser comprovado

Leia mais

QUESTIONAMENTOS ACERCA DO EDITAL DO PREGÃO ELETRÔNICO AA Nº 42/2012 - BNDES. Em resposta aos questionamentos formulados, o BNDES esclarece:

QUESTIONAMENTOS ACERCA DO EDITAL DO PREGÃO ELETRÔNICO AA Nº 42/2012 - BNDES. Em resposta aos questionamentos formulados, o BNDES esclarece: QUESTIONAMENTOS ACERCA DO EDITAL DO PREGÃO ELETRÔNICO AA Nº 42/2012 - BNDES Prezada Senhora, Em resposta aos questionamentos formulados, o BNDES esclarece: 1. EDITAL - Item 4.12.4 inciso I - Qual documento

Leia mais

SOLICITAÇÃO DE COTAÇÃO IICA/NEAD Nº 005/2008 Data: 29/02/2008. EMPRESA CONVIDADA: Telefone: Fax: Endereço: Cidade: Estado:

SOLICITAÇÃO DE COTAÇÃO IICA/NEAD Nº 005/2008 Data: 29/02/2008. EMPRESA CONVIDADA: Telefone: Fax: Endereço: Cidade: Estado: SOLICITAÇÃO DE COTAÇÃO IICA/NEAD Nº 005/2008 Data: 29/02/2008 EMPRESA CONVIDADA: Telefone: Fax: Endereço: Cidade: Estado: Prezado (a) Senhor (a), O Projeto de Cooperação para Apoio às Políticas e à Participação

Leia mais

FUNDAÇÃO THEODOMIRO SANTIAGO TERMO DE REFERÊNCIA COTAÇÃO PRÉVIA DE PREÇO Nº 201150062 TIPO: MENOR PREÇO

FUNDAÇÃO THEODOMIRO SANTIAGO TERMO DE REFERÊNCIA COTAÇÃO PRÉVIA DE PREÇO Nº 201150062 TIPO: MENOR PREÇO TERMO DE REFERÊNCIA COTAÇÃO PRÉVIA DE PREÇO Nº 201150062 TIPO: MENOR PREÇO A FUNDAÇÃO THEODOMIRO SANTIAGO, entidade privada sem fins lucrativos, inscrita no Cadastro Nacional de Pessoa Jurídica do Ministério

Leia mais

EDITAL TOMADA DE PREÇO PARA AQUISIÇÃO DE TUBOS DE CONCRETO

EDITAL TOMADA DE PREÇO PARA AQUISIÇÃO DE TUBOS DE CONCRETO PREFEITURA MUNICIPAL DE SOLEDADE SECRETARIA MUNICIPAL DE OBRAS E AGRICULTURA EDITAL TOMADA DE PREÇOS Nº 38/2015 TIPO MENOR PREÇO EDITAL TOMADA DE PREÇO PARA AQUISIÇÃO DE TUBOS DE CONCRETO O PREFEITO MUNICIPAL

Leia mais

ASSOCIAÇÃO DE ARTESANATO E ESTILO - ARTEST

ASSOCIAÇÃO DE ARTESANATO E ESTILO - ARTEST Cotação Prévia de Preços n 002/2013 Convênio nº 35/2013 - SEBRAE/ ARTEST Menor preço Cotação Prévia de Preços na modalidade menor preço para contratação de empresa especializada nos serviços de GESTÃO

Leia mais

PREFEITURA DE PALMAS SECRETARIA MUNICIPAL EXTRAORDINÁRIA DOS JOGOS INDÍGENAS EDITAL DE CHAMAMENTO PÚBLICO Nº 001/2015/SEJI

PREFEITURA DE PALMAS SECRETARIA MUNICIPAL EXTRAORDINÁRIA DOS JOGOS INDÍGENAS EDITAL DE CHAMAMENTO PÚBLICO Nº 001/2015/SEJI PREFEITURA DE PALMAS SECRETARIA MUNICIPAL EXTRAORDINÁRIA DOS JOGOS INDÍGENAS EDITAL DE CHAMAMENTO PÚBLICO Nº 001/2015/SEJI EDITAL DE CHAMAMENTO PÚBLICO PARA SELEÇÃO DE INTERESSADOS NA OPERAÇÃO E GESTÃO

Leia mais

Prefeitura Municipal de Floriano Peixoto 01.612.289/0001-62 Avenida Alfredo Joahnes Dücker - 99.910-000 - Floriano Peixoto/RS EDITAL DE LICITAÇÃO

Prefeitura Municipal de Floriano Peixoto 01.612.289/0001-62 Avenida Alfredo Joahnes Dücker - 99.910-000 - Floriano Peixoto/RS EDITAL DE LICITAÇÃO Prefeitura Municipal de Floriano Peixoto 01.612.289/0001-62 Avenida Alfredo Joahnes Dücker - 99.910-000 - Floriano Peixoto/RS EDITAL DE LICITAÇÃO Processo...: 8/2015 Modalidade.: Convite Número...: 6/2015

Leia mais

OBJETO: Aquisição de licenças de softwares de editoração para a plataforma Windows XP e de treinamento na ferramenta Adobe SC 4 Design Standart

OBJETO: Aquisição de licenças de softwares de editoração para a plataforma Windows XP e de treinamento na ferramenta Adobe SC 4 Design Standart MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS SRTVS

Leia mais

COMPANHIA DE GAS DO CEARA COTAÇÃO DE PREÇOS Nº 20150378 DECRETO Nº 28.397, DE 21 DE SETEMBRO DE 2006

COMPANHIA DE GAS DO CEARA COTAÇÃO DE PREÇOS Nº 20150378 DECRETO Nº 28.397, DE 21 DE SETEMBRO DE 2006 COMPANHIA DE GAS DO CEARA COTAÇÃO DE PREÇOS Nº 20150378 DECRETO Nº 28.397, DE 21 DE SETEMBRO DE 2006 PREÂMBULO Termo de Participação, via meio eletrônico, para a seleção da melhor proposta para aquisição

Leia mais

PREFEITURA MUNICIPAL DE FRANCA Secretaria de Planejamento e Gestão Econômica Divisão de Compras e Licitações Contrato nº /08

PREFEITURA MUNICIPAL DE FRANCA Secretaria de Planejamento e Gestão Econômica Divisão de Compras e Licitações Contrato nº /08 MINUTA 1 1 TERMO DE CONTRATO Tomada de Preços nº 041/08 Processo nº 31.744/08 Contratante: Prefeitura Municipal de Franca Contratada: Valor: R$ ( ) OBJETO: AQUISIÇÃO E INSTALAÇÃO DE EQUIPAMENTOS PARA SISTEMA

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N. º 16/2010 DGP/ INEP PROCESSO N.º 23036.001494/2010-18

EDITAL DO PREGÃO ELETRÔNICO N. º 16/2010 DGP/ INEP PROCESSO N.º 23036.001494/2010-18 INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSTICOS, AQUISIÇÕES E CONVÊNIOS COORDENAÇÃO DE AQUISIÇÕES

Leia mais

PORTARIA CAU/SP Nº 063, DE 31 DE AGOSTO DE 2015.

PORTARIA CAU/SP Nº 063, DE 31 DE AGOSTO DE 2015. PORTARIA CAU/SP Nº 063, DE 31 DE AGOSTO DE 2015. Aprova a Instrução Normativa nº 06, de 31 de agosto de 2015, que regulamenta os trâmites administrativos dos Contratos no âmbito do Conselho de Arquitetura

Leia mais

Fundação de Apoio à Tecnologia e Ciência FUNDAÇÃO DE APOIO À CIÊNCIA E TECNOLOGIA EDITAL DE PREGÃO ELETRÔNICO N 92092-03/2010

Fundação de Apoio à Tecnologia e Ciência FUNDAÇÃO DE APOIO À CIÊNCIA E TECNOLOGIA EDITAL DE PREGÃO ELETRÔNICO N 92092-03/2010 FUNDAÇÃO DE APOIO À CIÊNCIA E TECNOLOGIA EDITAL DE PREGÃO ELETRÔNICO N 92092-03/2010 A Fundação de Apoio à Ciência e Tecnologia - FATEC, por meio de sua pregoeira, Claudia Pippi Lorenzoni torna público

Leia mais

MINISTÉRIO DA FAZENDA SUPERINTENDÊNCIA DE SEGUROS PRIVADOS COMISSÃO PERMANENTE DE LICITAÇÕES PROCESSO Nº. 15414.300110/2008-40 PREGÃO ELETRÔNICO Nº

MINISTÉRIO DA FAZENDA SUPERINTENDÊNCIA DE SEGUROS PRIVADOS COMISSÃO PERMANENTE DE LICITAÇÕES PROCESSO Nº. 15414.300110/2008-40 PREGÃO ELETRÔNICO Nº A Superintendência de Seguros Privados SUSEP, no Estado do Rio de Janeiro, mediante Pregoeiro designado pela Portaria SUSEP n 3.053, de 14 de outubro de 2008, torna público que realizará às 14 horas, do

Leia mais

COTAÇÃO PRÉVIA DE PREÇOS EDITAL Nº 008/2015

COTAÇÃO PRÉVIA DE PREÇOS EDITAL Nº 008/2015 COTAÇÃO PRÉVIA DE PREÇOS EDITAL Nº 008/2015 CONVÊNIO Nº: 812779/2014 SDH/PR PROCESSO LICITATÓRIO Nº: 012/2015 TIPO: Cotação prévia de preços / Menor preço OBJETO: Contratação de Seguro contra Acidentes

Leia mais

Município de Xangri-Lá Fone: (51) 3689-2400 www.xangrila.rs.gov.br

Município de Xangri-Lá Fone: (51) 3689-2400 www.xangrila.rs.gov.br EDITAL Nº 62/2012 PREGÃO ELETRÔNICO 34/2012 PROCESSO DE DESPESA: 2318/2012 (SEC. DE EDUCAÇÃO) PROCESSO DE LICITAÇÃO 2318/2012 PROCESSO DE COMPRA 45-12 ABERTURA: 29/03/2012 HORÁRIO: 15 horas O Prefeito

Leia mais

COTAÇÃO PREVIA DE PREÇOS Nº 005/2015

COTAÇÃO PREVIA DE PREÇOS Nº 005/2015 Tipo: Menor preço COTAÇÃO PREVIA DE PREÇOS Nº 005/2015 A CONFEDERAÇÃO BRASILEIRA DO DESPORTO UNIVERSITÁRIO - CBDU, entidade privada sem fins lucrativos, inscrita sob o CNPJ nº 42.467.787/0001-46, com sede

Leia mais

TOMADA DE PREÇOS Nº 001/2010. SESSÃO DE ABERTURA: Local: Rua Pamplona 1200 7º andar Horário: 10:30 horas do dia 08 de março de 2.

TOMADA DE PREÇOS Nº 001/2010. SESSÃO DE ABERTURA: Local: Rua Pamplona 1200 7º andar Horário: 10:30 horas do dia 08 de março de 2. IMPORTANTE: PARA PARTICIPAR DA LICITAÇÃO O INTERESSADO DEVERÁ RETIRAR O EDITAL SOB PROTOCOLO COM 03 (TRÊS) DIAS DE ANTECEDENCIA NA SEDE DO CONSELHO SITUADO À RUA PAMPLONA, 1200 JD PAULISTA CEP: 01405-001

Leia mais

TERMO DE REFERÊNCIA COTAÇÃO PRÉVIA Nº 10/2014, REFERENTE AO CONVÊNIO SICONV Nº 794450/2013

TERMO DE REFERÊNCIA COTAÇÃO PRÉVIA Nº 10/2014, REFERENTE AO CONVÊNIO SICONV Nº 794450/2013 TERMO DE REFERÊNCIA COTAÇÃO PRÉVIA Nº 10/2014, REFERENTE AO CONVÊNIO SICONV Nº 794450/2013 O Instituto Tribos Jovens, associação civil sem fins lucrativos, com sede em Porto Seguro/BA, na Rua Saldanha

Leia mais

PROCESSO Nº 23036.002027/2008-91

PROCESSO Nº 23036.002027/2008-91 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE RECURSOS LOGÍSITICOS, AQUISIÇÕES E CONVÊNIOS Esplanada

Leia mais

TÍTULO DE CAPITALIZAÇÃO APLUBCAP ECO 2.1 MODALIDADE DADE INCENTIVO PAGAMENTO ÚNICO CONDIÇÕES GERAIS

TÍTULO DE CAPITALIZAÇÃO APLUBCAP ECO 2.1 MODALIDADE DADE INCENTIVO PAGAMENTO ÚNICO CONDIÇÕES GERAIS TÍTULO DE CAPITALIZAÇÃO APLUBCAP ECO.1 I INFORMAÇÕES INICIAIS SOCIEDADE DE CAPITALIZAÇÃO: APLUB CAPITALIZAÇÃO S. A. CNPJ: 88.076.30/0001-94 APLUBCAP ECO.1 MODALIDADE: INCENTIVO PROCESSO SUSEP Nº: 15414.0055/011-47

Leia mais

REGULAMENTO OPERACIONAL DO CERTAME

REGULAMENTO OPERACIONAL DO CERTAME Banco do Brasil - edital nº 2007/21407 (7420) - Registro de Preços - edital 8. REGULAMENTO OPERACIONAL DO CERTAME 8.2 CREDENCIAMENTO NO APLICATIVO LICITAÇÕES 8.2.7 Em se tratando de Microempresa ou Empresa

Leia mais

REPUBLICA FEDERATIVA DO BRASIL MINISTERIO DOS TRANSPORTES DEPARTAMENTO NACIONAL DE INFRA-ESTRUTURA DE TRANSPORTES PREGÃO ELETRÔNICO EDITAL Nº 398/2006

REPUBLICA FEDERATIVA DO BRASIL MINISTERIO DOS TRANSPORTES DEPARTAMENTO NACIONAL DE INFRA-ESTRUTURA DE TRANSPORTES PREGÃO ELETRÔNICO EDITAL Nº 398/2006 REPUBLICA FEDERATIVA DO BRASIL MINISTERIO DOS TRANSPORTES DEPARTAMENTO NACIONAL DE INFRA-ESTRUTURA DE TRANSPORTES PREGÃO ELETRÔNICO EDITAL Nº 398/2006 PROCESSO : 50600.000884/2006-13 Tipo de Licitação:

Leia mais

CARTA CONVITE Nº 013/2007 PROCESSO N.º 1.612/2007

CARTA CONVITE Nº 013/2007 PROCESSO N.º 1.612/2007 IMPORTANTE: PARA PARTICIPAR DA LICITAÇÃO O INTERESSADO DEVERÁ RETIRAR O EDITAL SOB PROTOCOLO NA SEDE DO CONSELHO SITUADO À RUA PAMPLONA, 1200 JD PAULISTA CEP: 01405-001 - DEPTO DE COMPRAS - 8º ANDAR. Regime

Leia mais

AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.

AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license. DECRETO Nº 5.450, DE 31 DE MAIO DE 2005 Regulamenta o pregão, na forma eletrônica, para aquisição de bens e serviços comuns, e dá outras providências. O PRESIDENTE DA REPÚBLICA, no uso da atribuição que

Leia mais

PREFEITURA MUNICIPAL DE FRANCA Secretaria de Planejamento e Gestão Econômica Divisão de Compras e Licitações Contrato nº /08

PREFEITURA MUNICIPAL DE FRANCA Secretaria de Planejamento e Gestão Econômica Divisão de Compras e Licitações Contrato nº /08 MINUTA 1 1 TERMO DE CONTRATO Tomada de Preços nº 019/08 Processo nº 5935/0/ Contratante: Prefeitura Municipal de Franca Contratada: Valor: R$ ( ) OBJETO: AQUISIÇÃO DE TERMINAIS DE AUTO ATENDIMENTO Pelo

Leia mais

TÍTULO DE CAPITALIZAÇÃO - APLUBCAP TRADICIONAL 16 MODALIDADE TRADICIONAL - PAGAMENTO ÚNICO

TÍTULO DE CAPITALIZAÇÃO - APLUBCAP TRADICIONAL 16 MODALIDADE TRADICIONAL - PAGAMENTO ÚNICO TÍTULO DE CAPITALIZAÇÃO - APLUBCAP TRADICIONAL 16 MODALIDADE TRADICIONAL - PAGAMENTO ÚNICO CONDIÇÕES GERAIS I INFORMAÇÕES INICIAIS SOCIEDADE DE CAPITALIZAÇÃO: APLUB CAPITALIZAÇÃO S/A CNPJ: 88.076.302/0001-94

Leia mais

CONDIÇÕES GERAIS DO PREMIUM CASH

CONDIÇÕES GERAIS DO PREMIUM CASH CONDIÇÕES GERAIS DO PREMIUM CASH I INFORMAÇÕES INICIAIS SOCIEDADE DE CAPITALIZAÇÃO: BRADESCO CAPITALIZAÇÃO S/A CNPJ: 33.010.851/0001-74 PREMIUM CASH PLANO PM 60/60 N - MODALIDADE: TRADICIONAL PROCESSO

Leia mais

CONFEDERAÇÃO BRASILEIRA DE HANDEBOL

CONFEDERAÇÃO BRASILEIRA DE HANDEBOL EDITAL DE LICITAÇÃO nº 002/2012 TOMADA DE PREÇOS PARA PRESTADORES DE SERVIÇOS E PRESTAÇÕES DE CONTAS NA GESTÃO DE PROJETOS A CBHb, de acordo com a Lei 10.264 de 16 de julho de 2001 Lei Agnelo/Piva, regulamentada

Leia mais

CG DA MODALIDADE TRADICIONAL PU CONDIÇÕES GERAIS DA ZURICHCAP TRADICIONAL PU 01

CG DA MODALIDADE TRADICIONAL PU CONDIÇÕES GERAIS DA ZURICHCAP TRADICIONAL PU 01 CONDIÇÕES GERAIS DA ZURICHCAP TRADICIONAL PU 01 I INFORMAÇÕES INICIAIS SOCIEDADE DE CAPITALIZAÇÃO: ZURICH BRASIL CAPITALIZAÇÃO S/A. CNPJ: 17.266.009/0001-41 ZURICHCAP TRADICIONAL PU 01 MODALIDADE: TRADICIONAL

Leia mais

PREGÃO PRESENCIAL Nº 005/2013 PROCESSO SECOM Nº 0357/2012. Alterações e Normas complementares M I N U T A

PREGÃO PRESENCIAL Nº 005/2013 PROCESSO SECOM Nº 0357/2012. Alterações e Normas complementares M I N U T A IMPORTANTE: PARA PARTICIPAR DA LICITAÇÃO O INTERESSADO DEVERÁ PREENCHER O RECIBO DE RETIRADA DE EDITAL, CONSTANTE DO ANEXO I E DEVOLVER COM ATÉ 24 HS DE ANTECEDENCIA DO CERTAME PREGÃO PRESENCIAL Nº 005/2013

Leia mais

EDITAL DO PREGÃO ELETRÔNICO N.º 21/2007 CGSI / INEP PROCESSO N.º 23036.001901/2007-91

EDITAL DO PREGÃO ELETRÔNICO N.º 21/2007 CGSI / INEP PROCESSO N.º 23036.001901/2007-91 MINISTÉRIO DA EDUCAÇÃO INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO TEIXEIRA INEP DIRETORIA DE GESTÃO E PLANEJAMENTO COORDENAÇÃO-GERAL DE LICITAÇÕES, CONTRATOS E CONVÊNIOS Esplanada dos

Leia mais

PROJETO BÁSICO PRESTAÇÃO DE SERVIÇOS ACADÊMICOS NA ÁREA DE EFICIÊNCIA ENERGÉTICA

PROJETO BÁSICO PRESTAÇÃO DE SERVIÇOS ACADÊMICOS NA ÁREA DE EFICIÊNCIA ENERGÉTICA PROJETO BÁSICO PRESTAÇÃO DE SERVIÇOS ACADÊMICOS NA ÁREA DE EFICIÊNCIA ENERGÉTICA IMPLEMENTAÇÃO DE PROJETO DE CURSO DE ESPECIALIZAÇÃO LATU SENSO EM EFICIÊNCIA ENERGÉTICA PARA COMPOR O PROGRAMA DE EFICIÊNCIA

Leia mais

Edital de convite para

Edital de convite para CÂMARA MUNICIPAL DE ARVOREZINHA EDITAL DE CONVITE N.º 004/2014 PROCESSO ADMINISTRATIVO Nº 006/2014 TIPO MENOR PREÇO POR ITEM ENTREGA DA DOCUMENTAÇÃO E ABERTURA DOS ENVELOPES DA DOCUMENTAÇÃO: 13/11/2014,

Leia mais