Contratando uma fábrica de software

2.513 visualizações

Publicada em

Publicada em: Tecnologia
1 comentário
5 gostaram
Estatísticas
Notas
  • 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
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
Sem downloads
Visualizações
Visualizações totais
2.513
No SlideShare
0
A partir de incorporações
0
Número de incorporações
35
Ações
Compartilhamentos
0
Downloads
0
Comentários
1
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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]

×