Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Contratando uma fábrica de software

2,712 views

Published on

Published in: Technology
  • Fabiano, meu nome é Ricardo e sou Superintendente de TI da FINEP. Eu gostaria de receber uma cópia de sua apresentação.
    Meu email é: roliveira@finep.gov.br
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Contratando uma fábrica de software

  1. 1. Contratando uma Fábrica de Software Tribunal Superior Eleitoral
  2. 2. Fabiano Damasceno Sousa Falcão <ul><li>Engenheiro de Software do Escritório de Processos e Padrões de TI (EPP) da Assessoria de Gestão e Planejamento (ASPLAN) da Secretaria de Tecnologia da Informação (STI) do TSE. </li></ul><ul><ul><li>Vinculo: Servidor Público (Agosto de 2007). </li></ul></ul><ul><li>Bacharel em Ciência da Computação com Especialização (lato sensu) em Engenharia de Software. </li></ul><ul><li>Mais de 5 anos de atuação em Fábricas de Softwares em empresas como CTIS, Politec, Cast, Accenture do Brasil . </li></ul><ul><li>Consultor em Planejamento Estratégico, Governança e Auditoria de TI da ASPLAN/STI/TSE; </li></ul><ul><li>Interesse por licitações e contratações de TI. </li></ul>
  3. 3. Demanda esmagadora
  4. 7. Fonte: Governance of Outsourcing. Rolling Meadows: ITGI, 2005.
  5. 8. Fonte: Governance of Outsourcing. Rolling Meadows: ITGI, 2005.
  6. 9. Modelo Antigo de Contratação de Serviços de TI <ul><li>Consiste na reunião de todos os serviços de informática do órgão em um único e grande contrato , adjudicado a uma única empresa , com pagamentos realizados exclusivamente por hora-trabalhada . </li></ul><ul><ul><li>(Contratação de Serviços de TI - Augusto Sherman Cavalcanti) </li></ul></ul>
  7. 10. Modelo Antigo de Contratação de Serviços de TI <ul><li>Único contrato de serviços de TI </li></ul><ul><li>Ausência de parcelamento do objeto </li></ul><ul><ul><li>Potencial limitação à competição </li></ul></ul><ul><ul><li>Risco de onerar indevidamente o contrato </li></ul></ul><ul><ul><li>Risco estratégico (dependência) </li></ul></ul><ul><ul><li>Risco na segurança da informação </li></ul></ul><ul><li>Pagamento por homem-hora (HH) </li></ul><ul><ul><li>Risco exclusivo do contratante </li></ul></ul><ul><ul><li>Anti-economicidade: “Paradoxo lucro-incompetência” </li></ul></ul><ul><ul><li>Risco de remuneração de horas improdutivas </li></ul></ul><ul><ul><li>(Contratação de Serviços de TI - Augusto Sherman Cavalcanti) </li></ul></ul>
  8. 11. Novo Modelo de Contratação de Serviços de TI <ul><li>Estruturação do quadro de pessoal de TI; </li></ul><ul><li>Planejamento da contratação; </li></ul><ul><li>Parcelamento dos serviços; </li></ul><ul><li>Prestação e pagamento por serviços mensurados por resultado alcançado e verificado, e não por horas trabalhadas; </li></ul><ul><li>Avaliação de qualidade dos serviços; </li></ul><ul><li>Controle efetivo da execução dos serviços (aperfeiçoamento da gestão do contrato); </li></ul><ul><ul><li>(Contratação de Serviços de TI - Augusto Sherman Cavalcanti) </li></ul></ul>
  9. 12. Contratação Mensurada por Resultados <ul><li>Essa forma de execução permite que o pagamento da contratada seja feito com base na mensuração dos serviços e dos resultados alcançados e verificados, evitando-se o pagamento por horas-trabalhadas ou por horas de disponibilidade do pessoal (postos de serviço). </li></ul><ul><li>Assim, a Administração paga somente pelos produtos e serviços efetivamente realizados, verificados e aceitos conforme as métricas e os padrões previamente estabelecidos (IN/SLTI04/2010, art.15). </li></ul><ul><li>(Contratação de Serviços de TI - Augusto Sherman Cavalcanti) </li></ul>
  10. 13. Contratação Mensurada por Resultados <ul><li>O planejamento da contratação deve privilegiar a eficácia,ou seja a mensuração dos resultados alcançados (ou o estabelecimento de Acordo de Nível de Serviço ) em contraposição à simples locação de mão-de-obra (vide Decreto 2.271/1997, art. 3º, §1º). </li></ul><ul><li>Ou seja, interessa , no prazo fixado, a obtenção dos resultados ou produtos , em conformidade com as especificações , qualidade e nível de serviços preestabelecidos, independentemente de quais ou quantos funcionários a empresa empregou. </li></ul><ul><li>(Contratação de Serviços de TI - Augusto Sherman Cavalcanti) </li></ul>
  11. 14. Contratação Mensurada por Resultados <ul><li>Fundamento Constitucional: </li></ul><ul><li>Princípio da Eficiência : o pagamento pelo resultado incentiva a eficiência no contratado, que tentará organizar o trabalho no sentido de atingir o resultado estabelecido a partir do melhor rendimento que estiver ao seu alcance. </li></ul><ul><li>Como corolário da eficiência, o pagamento por resultado dirige a atenção da Administração para o controle da eficácia da contratação. </li></ul><ul><li>Também como corolário da eficiência, o pagamento por resultado incentiva o contratado a o atingimento dos padrões desejados de qualidade do produto ou serviço fornecido. </li></ul><ul><li>(Contratação de Serviços de TI - Augusto Sherman Cavalcanti) </li></ul>
  12. 15. Definição de Fábrica de Software <ul><li>“ Um processo estruturado , controlado e melhorado de forma contínua, considerando abordagens de engenharia industrial, orientado para o atendimento a múltiplas demandas de natureza e escopo distintas, visando à geração de produtos de software , conforme os requisitos documentados dos usuários e/ou cliente, da forma mais produtiva e econômica possível ”. </li></ul><ul><li>(FERNANDES, 2004) </li></ul><ul><li>O termo Fábrica de Software foi empregado pela primeira vez em 1969 , pela japonesa Hitachi, mas só começou a ficar popular no início dos anos 90 . </li></ul><ul><li>A idéia era aplicar conceitos da indústria em geral em ambientes de desenvolvimento de software, de forma a aumentar a produtividade e diminuir prazos e custos . </li></ul>
  13. 19. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PLANEJAMENTO DA CONTRATAÇÃO </li></ul><ul><ul><li>Esta atividade visa: </li></ul></ul><ul><ul><ul><li>Identificar e gerenciar os riscos envolvidos inerentes ao objeto e tipo de contratação; </li></ul></ul></ul><ul><ul><ul><li>Alinhar o contrato aos planejamentos estratégicos do órgão e de sua área de TI, e </li></ul></ul></ul><ul><ul><ul><li>Garantir que os recursos , não apenas os financeiros, mas, principalmente, os humanos , sejam bem utilizados. </li></ul></ul></ul><ul><li>PLANEJAMENTO DO ÓRGÃO E DE SUA ÁREA DE TI </li></ul><ul><ul><li>Softwares vinculados a objetivos estratégicos que desejam encaminhá-los para Fábrica de Software contratada; </li></ul></ul><ul><ul><ul><li>Existem riscos operacionais para o órgão inerentes à natureza do contrato de Fábrica de Software, ao próprio objeto contratado e à maturidade organizacional das partes contratuais. </li></ul></ul></ul><ul><ul><ul><li>A decisão de quais projetos de softwares estratégicos serão realizados, pela Fábrica de Software contratada deve ser cuidadosamente analisada, com base em risco contratuais, administrativos, técnicos e políticos . </li></ul></ul></ul>
  14. 21. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>RECURSOS HUMANOS NECESSÁRIOS A GESTÃO CONTRATUAL </li></ul><ul><ul><li>esforço de gestão contratual de uma Fábrica de Software é bastante alto e complexo , ao contrário da contratação de serviços por postos de trabalho; </li></ul></ul><ul><ul><ul><li>Grande esforço com emissão contínua de Ordens de Serviço (OS) </li></ul></ul></ul><ul><ul><ul><ul><li>Elaboração desses artefatos </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Produtos e serviços entregues têm que ser avaliados com base nas especificações da OS e nos critérios de qualidade e prazo estabelecidos no contrato. </li></ul></ul></ul></ul><ul><ul><li>A área de TI deve destacar servidores qualificados em gestão contratual, processos, métricas de softwares e no software em desenvolvimento  fiscais do contrato e membros da comissão de recebimento provisório e definitivo . </li></ul></ul><ul><ul><ul><li>Comprometendo parte dos recursos humanos da área de TI na atividade de gestão contratual . </li></ul></ul></ul>
  15. 22. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>RECURSOS HUMANOS NECESSÁRIOS A GESTÃO CONTRATUAL </li></ul><ul><ul><li>Demandar grande esforço nas áreas requisitantes dos softwares com relação ao uso de ordens de serviço. </li></ul></ul><ul><ul><ul><li>participação da área requisitante na elaboração dos artefatos de especificações dos requisitos dos softwares; </li></ul></ul></ul><ul><ul><ul><li>produtos e serviços entregues têm que ser avaliados sob a ótica da aderência aos requisitos de negócio estabelecidos . </li></ul></ul></ul><ul><ul><li>a área requisitante deve destacar servidores devidamente qualificados nos processos de negócio suportados pelos softwares, em construção pela Fábrica, para participarem do esforço de gestão contratual, </li></ul></ul><ul><ul><ul><li>Comprometendo parte dos recursos humanos da área requisitante nesse processo de trabalho. </li></ul></ul></ul>
  16. 23. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>RECURSOS HUMANOS NECESSÁRIOS A GESTÃO CONTRATUAL </li></ul><ul><ul><li>Para executar adequadamente as atividades relativas à contratação de Fábrica de Software e à gestão do contrato decorrente, inclusive as de caráter estruturante, o órgão tem que contar com quantidade de servidores (pessoas) compatível com a carga de trabalho gerada por essas atividades . </li></ul></ul><ul><ul><ul><li>A disponibilidade de pessoal para planejar a contratação e posteriormente efetuar a gestão contratual deve, inclusive, ser considerada como fator de risco na avaliação da viabilidade da contratação. </li></ul></ul></ul>
  17. 24. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>ESTUDOS TÉCNICOS PRELIMINARES </li></ul><ul><ul><li>A elaboração dos estudos técnicos preliminares é a primeira etapa do planejamento de uma contratação; </li></ul></ul><ul><ul><ul><li>Sem estes estudos técnicos preliminares, existe o alto risco de o órgão: </li></ul></ul></ul><ul><ul><ul><ul><li>Consumir recursos financeiros, esforço administrativo e tempo para efetuar a elaboração do termo de referência ou </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Do projeto básico de baixa qualidade , que resultará em uma licitação e gestão contratual infrutíferas , cuja inviabilidade poderia ter sido verificada na primeira etapa do planejamento da contratação. </li></ul></ul></ul></ul>
  18. 25. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PROCESSO DE SOFTWARE </li></ul><ul><ul><li>A estrutura do processo de software estabelece a fundação para um processo completo de engenharia de software, identificando um pequeno número de atividades que são aplicáveis a todos os projetos de software , independentemente do seu tamanho ou complexidade. Além disso, a estrutura de processo engloba um conjunto de atividades guarda-chuva que são aplicáveis em todo o processo de software (PRESSMAN, 2010). </li></ul></ul><ul><ul><li>O uso de um processo de software inadequado pode reduzir a qualidade ou a utilidade do produto de software a ser desenvolvido e/ou aumentar os custos de desenvolvimento (SOMMERVILE, 2007). </li></ul></ul>
  19. 26. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PROCESSO DE SOFTWARE </li></ul><ul><ul><li>12 auditorias avaliação de controles gerais de Tecnologia da Informação nos órgãos público federais, em 2010 e 2011 , o TCU detectou irregularidades relacionadas à inexistência , deficiências e a falhas de processos de softwares. </li></ul></ul><ul><ul><li>Para a inexistência e falha de processos de softwares, o TCU listou como efeitos/consequências: </li></ul></ul><ul><ul><ul><li>Deficiência no processo de contratação, decorrente da inexistência de metodologia que assegure boa contratação de desenvolvimento de sistemas. (efeito real) </li></ul></ul></ul><ul><ul><ul><li>Inexistência de parâmetros de aferição de qualidade para contratação de desenvolvimento de sistemas. (efeito real) </li></ul></ul></ul>
  20. 27. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PROCESSO DE SOFTWARE </li></ul><ul><ul><li>Para a deficiência de processos de softwares, o TCU listou como efeitos/consequências: </li></ul></ul><ul><ul><ul><li>Processo de desenvolvimento de sistemas lento e sistemas de informação ineficazes . (efeito potencial) </li></ul></ul></ul><ul><ul><ul><li>Perda de informações por causa de sistemas pouco robustos, sujeitos a falhas de segurança, seja por fraude, seja por uso incorreto. (efeito potencial) </li></ul></ul></ul><ul><ul><ul><li>Execução de contratos de prestação de serviços de desenvolvimento sem métricas adequadas nem etapas claras com produtos para cada etapa. (efeito potencial) </li></ul></ul></ul><ul><ul><ul><li>Sistemas de difícil manutenção, sem documentação, em que apenas quem desenvolveu detém o conhecimento. Esse caso pode ser ainda mais sério se o desenvolvedor for contratado externamente. (efeito potencial) </li></ul></ul></ul>
  21. 28. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PROCESSO DE SOFTWARE </li></ul><ul><ul><li>o TCU recorrentemente recomenda que os órgãos auditados: </li></ul></ul><ul><ul><ul><li>Definam um processo de software previamente às futuras contratações de serviços de desenvolvimento ou manutenção de software, vinculando o contrato com o processo de software, sem o qual o objeto não estará precisamente definido. </li></ul></ul></ul><ul><ul><ul><li>Quando do estabelecimento dos processos de software, considerem as Normas NBR ISO/IEC 12.207 e 15.504, e as práticas contidas no Cobit 4.1, processo PO8.3 - Padrões de desenvolvimento e de aquisições. </li></ul></ul></ul><ul><ul><ul><li>Aprove e publique o processo de desenvolvimento de software, com vistas a assegurar a aderência das rotinas de trabalho da área de TI ao processo definido pelo órgão; </li></ul></ul></ul>
  22. 29. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PROCESSO DE SOFTWARE </li></ul><ul><ul><li>Em auditoria na Anatel , o TCU constatou que a Anatel possuía um nível de capacidade/maturidade de processo de desenvolvimento de software gerenciado , no entanto, embora este processo possuísse os elementos essenciais definidos na matriz de planejamento da fiscalização do TCU, o processo ainda carecia de aprovação e publicação , com vistas a assegurar a aderência das rotinas de trabalho da área de TI da Agência ao processo por ela definido. Esta falta de aderência esta relacionada à deficiência de institucionalização do processo de software , que dependem diretamente da aprovação e patrocínio do processo por parte da alta administração, seja de TI ou de negócio; </li></ul></ul><ul><ul><li>TCU constatou em auditoria no Ministério da Saúde que o processo de software do órgão também não tinha sido aprovado e publicado oficialmente para uso no órgão, bem como ele apresentava falhas na definição dos papéis e responsabilidades . </li></ul></ul>
  23. 30. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PROCESSO DE SOFTWARE </li></ul><ul><ul><li>Acrescenta-se ainda que o gestor de TI do Ministério da Saúde , quando questionado acerca da ausência nos documentos de requisitos das assinaturas dos responsáveis envolvidos , o que corresponde ao registro de aceite, afirmou que parte dos requisitos produzidos pelo processo de software não são assinados pelos clientes, em virtude da dificuldade em obter essas assinaturas devido à cultura do local . </li></ul></ul><ul><ul><li>Em auditoria realizada no Ministério das Relações Exteriores , o constatou que embora este órgão possuísse uma metodologia de desenvolvimento de software, não ficou comprovada sua aplicabilidade . Esta irregularidade também está relacionada à deficiência de institucionalização do processo de software e provavelmente também a um alto grau de diferença (“gap”) entre a maturidade real do processo na organização e maturidade pretendida , aquela apresentada e definida na metodologia. </li></ul></ul>
  24. 31. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PROCESSO DE SOFTWARE </li></ul><ul><ul><li>No relatório de auditoria no TRT/2ª Região , TCU menciona que todo órgão ou entidade deve adotar metodologia de desenvolvimento de software que assegure a boa contratação de desenvolvimento de sistemas e de parâmetros de aferição de qualidade para essa contratação, de modo a assegurar níveis mínimos de padronização e segurança . </li></ul></ul><ul><ul><ul><li>O TCU também afirma que em razão da inexistência de processo de desenvolvimento de software institucionalizado, aprovado e publicado no âmbito do órgão auditado, toda e qualquer contratação para desenvolvimento de sistemas apresentará falhas insanáveis , ante o vício na origem. Ressaltou-se que a falta de domínio do processo fragiliza o órgão, que acaba por ter que se submeter aos critérios definidos pelas contratadas . </li></ul></ul></ul><ul><ul><li>Não se pode exigir do fornecedor uma certificação (MPS.BR ou CMMI) de nível de maturidade superior ao nível atual do contratante. </li></ul></ul>
  25. 32. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>MODELO DE EXECUÇÃO DO OBJETO </li></ul><ul><ul><li>Durante a fase de planejamento da contratação deve ser elaborado um modelo de execução do objeto que esteja de acordo com os objetivos contratuais pretendidos e que considere a cultura e maturidade organizacional , bem como, deve ter conformidade com legislação e da jurisprudência que se aplicam a qualquer contratação, e também aos regulamentos internos ao órgão. </li></ul></ul><ul><li>ORDEM DE SERVIÇO </li></ul><ul><ul><li>Documento utilizado para solicitar à contratada a prestação de serviço ou fornecimento de bens relativos ao objeto do contrato ; </li></ul></ul><ul><ul><li>O modelo de Ordem de Serviço deve conter o conteúdo mínimo indicado na jurisprudência do TCU e na IN - SLTI 4/2010 ; </li></ul></ul><ul><ul><li>Deve ser previsto no Modelo de Ordem de Serviço a possibilidade de entregas parceladas do objeto contratado. </li></ul></ul><ul><ul><li>Deve ser estipulado pelo órgão público o método ou processo pelo qual as Ordens de Serviço são utilizadas como instrumento de controle nas etapas de solicitação , acompanhamento , avaliação , atestação e pagamento de serviços. </li></ul></ul>
  26. 33. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>MEDIÇÕES DOS SERVIÇOS </li></ul><ul><ul><li>Os esforços de desenvolvimento e a manutenção de software são distribuídos em percentuais do “Ponto de Função”. </li></ul></ul><ul><ul><li>“ Tabela de Itens Não Mensuráveis ”  esforço de algumas atividades relevantes não são passíveis de serem pontuadas pela técnica de Análise de Pontos de Função </li></ul></ul><ul><ul><li>A técnica definida pela NESMA (Netherlands Software Metrics Users Association) para contagem de Pontos de Função normalmente é utilizada nas atividades de estimativa e a técnica do IFPUG (International Function Point Users Group) para atividades de mensuração dos serviços descritos nas Ordens de Serviço. </li></ul></ul><ul><ul><li>Recomenda-se que exista um profissional capacitado na técnica de Pontos de Função, se possível com certificação CFPS (Certified Function Points Specialist) do IFPUG, para validar as estimativas e mensurações de tamanho funcional das Ordens de Serviços, bem como, para atuar nas divergências das mensurações realizadas pelas partes </li></ul></ul><ul><ul><ul><li>+- 34 CFPS em Brasília. </li></ul></ul></ul>
  27. 34. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>PRAZO DE ATENDIMENTO DOS SERVIÇOS PELA FÁBRICA DE SOFTWARE </li></ul><ul><ul><li>O prazo de cada serviço contratado deve ser formalizado na Ordem de Serviço </li></ul></ul><ul><ul><li>O descumprimento deste prazo sujeitará, sem motivo justificável , a Fábrica de Software a aplicação de penalidade contratual. </li></ul></ul><ul><ul><li>D eve ser cuidadosamente definido os prazos de correção de produtos e serviços entregues com defeitos, durante o procedimento de recebimento do objeto ou de garantia do produto e serviço. </li></ul></ul><ul><li>PROTOCOLO DE COMUNICAÇÃO ENTRE CONTRATANTE E CONTRATADA AO LONGO DO CONTRATO </li></ul><ul><ul><li>Os contratos de Fábrica de Software são caracterizados pelo pagamento vinculado a produtos e serviços entregues e definição de requisitos e de elementos contratuais que impedem ou reduzem a ingerência do órgão público sobre a administração da contratada, que poderia caracterizar terceirização ilegal. </li></ul></ul>
  28. 35. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>FORMA DE PAGAMENTO DO SERVIÇO </li></ul><ul><ul><li>Os pagamentos das Ordens de Serviços são realizados em conformidade aos percentuais representativos do tamanho em pontos de função , determinados pelo percentual de esforço das fases ou disciplinas do processo de software do órgão. </li></ul></ul><ul><li>CONTROLE DA EXECUÇÃO DA ORDEM DE SERVIÇO </li></ul><ul><ul><li>Controlar a execução de uma ordem de serviço da Fábrica de Software equivale ao controle de projetos (FERNANDES, 2004). </li></ul></ul><ul><ul><li>Deve existir mecanismos que permitem controlar formalmente as mudanças de escopo, do cronograma e de custo das Ordens de Serviços. </li></ul></ul><ul><ul><ul><li>É imprescindível estes registros, análises, aprovações e formalizações das mudanças devido aos efeitos contratuais da Ordem de Serviço original , principalmente, os relacionados aos prazos de entrega. As mudanças podem significar ampliação dos prazos de execução dos serviços. </li></ul></ul></ul>
  29. 36. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>AVALIAÇÃO DA CONFORMIDADE DOS PRODUTOS E DOS SERVIÇOS ENTREGUES PELA FÁBRICA DE SOFTWARE </li></ul><ul><ul><li>De acordo com a jurisprudência do TCU, é necessário definir como o órgão contratante efetuará o recebimento , provisório e definitivo, do objeto , nos termos exigidos no Art. 40, inciso XVI da Lei nº 8.666/1993. </li></ul></ul><ul><ul><li>Nos termos no art. 73 da Lei nº 8.666/1993, o fiscal receberá provisoriamente os produtos de serviço para que em um decurso de tempo verifique e comprove a adequação do objeto aos termos contratuais . </li></ul></ul><ul><ul><ul><li>Estes termos são os critérios de avaliação de conformidade dos produtos e dos serviços entregues pela fábrica de software. </li></ul></ul></ul><ul><ul><li>No caso do recebimento de serviços, os critérios de avaliação devem abranger métricas , indicadores , inclusive de qualidade, segundo parâmetros e prazos aceitáveis. </li></ul></ul><ul><ul><li>Os critérios de avaliação dos produtos entregues pela Fábrica de Software são geralmente os critérios de avaliação de qualidade dos produtos do processo de software do órgão contratante. </li></ul></ul>
  30. 37. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>AVALIAÇÃO DA CONFORMIDADE DOS PRODUTOS E DOS SERVIÇOS ENTREGUES PELA FÁBRICA DE SOFTWARE </li></ul><ul><ul><li>A área requisitante do software também participa dessa etapa de recebimento provisório </li></ul></ul><ul><ul><ul><li>Deve emitir parecer sobre a aderência dos artefatos aos requisitos da contratação voltados ao negócio ; </li></ul></ul></ul><ul><ul><li>Portanto, é interessante que haja um duplo recebimento , pelo fiscal e pela área requisitante. </li></ul></ul>
  31. 38. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>DESVIOS DE QUALIDADE E DE CONFORMIDADE </li></ul><ul><ul><li>Nos termos no art. 69 da Lei nº 8.666/1993, o contratado é obrigado a reparar , corrigir , remover , reconstruir ou substituir , às suas expensas, no total ou em parte, o objeto do contrato em que se verificarem vícios , defeitos ou incorreções resultantes da execução ou de materiais empregados . </li></ul></ul><ul><ul><li>Assim como é imprescindível definir como o contratante efetuará o recebimento, provisório e definitivo, também é indispensável definir como as demandas de correção dos produtos e serviços serão encaminhados à Contratada, bem como, os prazos e responsabilidades contratuais pertinentes. </li></ul></ul><ul><ul><li>Impactam no calculo dos indicadores de qualidade dos serviços , que são formalizados no termo de recebimento definitivo do objeto. </li></ul></ul><ul><ul><li>No caso de ocorrência de divergências entre as partes contratuais quanto aos desvios de qualidade e conformidades identificados deve estabelecer as regras de resolução desta divergência no contrato. </li></ul></ul>
  32. 39. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>NÍVEIS DE SERVIÇO </li></ul><ul><ul><li>De acordo com a jurisprudência do TCU, é necessário definir níveis de serviços em contratos de prestação de serviços. </li></ul></ul><ul><ul><li>Em virtude da exigência de clareza do objeto , não é possível negociar acordos de nível de serviço , na acepção mundialmente aceita, popularizada no ITIL (Information Technology Infrastructure Library), pois após a assinatura do contrato, o órgão público não dispõe de muita flexibilidade para alterar as condições pactuadas . Assim, fica mais coerente com a legislação de licitações e contratos a utilização da expressão Nível Mínimo de Serviço Exigido , cujos parâmetros decorrerão dos requisitos obrigatórios do edital, ou da proposta vencedora, quando esta superar os requisitos obrigatórios. O Nível Mínimo de Serviço é formulado com base no levantamento do mercado, de modo que o órgão não estabeleça parâmetros não usuais ou que não sejam possíveis de ser atendidos pelos fornecedores, mas não deve ser objeto de negociação após a assinatura do contrato </li></ul></ul>
  33. 40. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>NÍVEIS DE SERVIÇO </li></ul><ul><ul><li>Antes da construção dos indicadores , os serviços e resultados esperados já deverão estar claramente definidos e identificados, diferenciando-se as atividades consideradas críticas das secundárias; </li></ul></ul><ul><ul><li>Os indicadores deverão ser objetivamente mensuráveis , de preferência facilmente coletáveis , relevantes e adequados à natureza e características do serviço e compreensíveis. </li></ul></ul><ul><ul><li>Evitar indicadores complexos ; </li></ul></ul><ul><ul><li>As metas devem ser realistas e definidas com base em uma comparação apropriada; </li></ul></ul><ul><ul><li>Os indicadores devem refletir fatores que estão sob controle do prestador do serviço ; </li></ul></ul><ul><ul><ul><li>Previsão de fatores, fora do controle do prestador, que possam interferir no atendimento das metas [para evitá-los] </li></ul></ul></ul>
  34. 41. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>GARANTIA DOS SERVIÇOS E PRODUTOS </li></ul><ul><ul><li>Deve ser estabelecido no contrato prazos e responsabilidades das correções emergências dos softwares cujo erro em operação pode significar grande prejuízo ao órgão público; </li></ul></ul><ul><ul><li>O prazo de garantia deve ser adequado para cobrir um período razoável que permita a descoberta de um número considerável de defeitos ocultos nos produtos ou serviços entregues pela Fábrica de Software. </li></ul></ul><ul><ul><li>Como pode ocorrer a situação de que um componente de software e/ou artefato referente a um serviço da Fábrica de Software seja alterado pelo órgão público ou por outro fornecedor por ele designado , para realização de atividades de manutenções, recomenda-se a definição de condições de manutenção da qualidade que não penalize a contratada na assunção de responsabilidades legais e contratuais que não lhe seja devido , mas a terceiros que alteraram os produtos com imperícia ou negligência, provocando os defeitos. </li></ul></ul>
  35. 42. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>TERMO DE REFERÊNCIA OU PROJETO BÁSICO </li></ul><ul><ul><li>Os Termos de Referência ou Projetos Básicos descrevem os elementos necessários e suficientes, com nível de precisão adequado, para subsidiar o processo licitatório; </li></ul></ul><ul><ul><ul><li>Estes documentos devem conter todos os elementos capazes de definir o objeto, de forma clara, concisa e objetiva, bem assim com nível de precisão adequado para caracterizar o bem ou o serviço. </li></ul></ul></ul><ul><ul><li>Devido ao aspecto evolucionário dos Processos de Desenvolvimento de Sistemas, recomenda-se que o Termo de Referência ou Projeto Básico descreva apenas requisitos que o órgão tem certeza acerca da sua imutabilidade e , de forma mais apropriada, referencie o documento que descreve detalhadamente o processo de software , este suscetível a alterações durante a vigência do contrato. Também deve-se definir a forma de comunicação das alterações do processos e os prazos para início de vigências das mudanças. </li></ul></ul>
  36. 43. PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWARE <ul><li>TERMO DE REFERÊNCIA OU PROJETO BÁSICO </li></ul><ul><ul><li>Alguns fatos recorrentes entre os órgãos públicos e que geram diversos problemas na execução dos contratos de Fábrica de Software são: </li></ul></ul><ul><ul><ul><li>Cópia de edital de outra instituição mais madura que contenha modelos de execução do objeto e de gestão do contrato para os quais o órgão não está preparado ; </li></ul></ul></ul><ul><ul><ul><li>Cópia de edital de outra instituição menos madura que contém modelos de execução do objeto e de gestão do contrato considerados insuficientes ao órgão (e.g. conjunto de sanções limitado). </li></ul></ul></ul>
  37. 44. Conclusão <ul><li>O principal problema observado é a falta de maturidade dos órgãos públicos no processo de planejamento da contratação de Fábrica de Software que impacta no modelo de gestão do contrato. </li></ul><ul><li>A capacitação de servidores da área de TI em planejamento de contratação de serviços de TI e em gestão dos contratos decorrentes é fundamental para que existam servidores minimamente capacitados para executar esses processos de planejamento e gestão . </li></ul><ul><li>Devem constar dos programas dos concursos públicos que selecionem servidores para atuar na área de gestão de TI . </li></ul><ul><li>Os servidores da área de TI devem também ser capacitados em processos de softwares e nos modelos de maturidade e capacidade de processos de software . </li></ul>
  38. 45. Obrigado! Fabiano Damasceno Sousa Falcão Escritório de Processos e Padrões de TI - EPP/ASPLAN/STI/TSE [email_address]

×