• Save
Contratando uma fábrica de software
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Contratando uma fábrica de software

  • 3,056 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,056
On Slideshare
3,024
From Embeds
32
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 32

http://fabiano-falcao.blogspot.com.br 21
http://fabiano-falcao.blogspot.com 11

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Título: Contratando uma fábrica de software: do planejamento licitatório às liçõesaprendidas.Tribunal: Tribunal Superior EleitoralNomes dos autores e e-mails:Augusto Cesar de Castro OvelarFabiano Damasceno Sousa FalcãoFrancisco Ítalo Lopes FrançaGrace Porto dos Santos VerasJusmar Chaves JúniorKelson da Costa MedeirosLeonardo Silva LeãoPriscila Andressa CorreaFase em que se encontra o projeto: Em produção.Tema do evento ao qual o trabalho está adequado: Governança em TI comênfase nas determinações dos órgãos de controles.
  • 2. Sinopse:Nas últimas décadas, os processos de negócios dos órgãos públicos federaisaumentaram a demanda de recursos de tecnologia da informação. O uso de taisrecursos é motivado pela necessidade de suportar ou aprimorar o cumprimentodos objetivos institucionais dos órgãos. Embora as necessidades tecnológicasdos órgãos públicos sejam ilimitadas, os recursos de TI são finitos e insuficientespara fazer frente às demandas. Entre os recursos identificados no ControlObjectives for Information and Related Technology, os aplicativos são aquelescom maior influência na percepção de valor de TI. Comumente, asparticularidades dos processos de negócios demandam o desenvolvimento deaplicativos sob encomenda. A produção desse tipo de aplicativo é limitada peladisponibilidade de profissionais da área de TI dos órgãos e pela quantidade deaplicativos em fase de manutenção. Como contorno a essa limitação, éfrequente a contratação de terceiros para o desenvolvimento de tais aplicativosno modelo conhecido como fábrica de software. Entretanto, para obter osbenefícios desse tipo de contratação, deve-se entender e gerenciar os riscos,desafios e requisitos legais associados. Recentes auditorias do Tribunal deContas da União revelaram várias deficiências relacionadas à contratação egestão de contratos de desenvolvimento de software nos órgãos públicosfederais auditados, exigindo assim uma melhor compreensão, por parte dosenvolvidos, do modelo de terceirização por meio de fábrica de software.
  • 3. 1 INTRODUÇÃOOs processos primários organizacionais, aqueles que representam as atividadesessenciais para que órgãos cumpram suas missões institucionais e alcancemseus objetivos estratégicos, ou seja, ajudam os órgãos a exercer seus papéisperante a sociedade, são cada vez mais suportados por serviços de Tecnologiada Informação (TI).Os serviços de TI objetivam aumentar o desempenho desses processos oureduzir ou eliminar as barreiras existentes à consecução eficiente e eficaz dosobjetivos destes processos de negócio suportados pela TI (OGC, 2007).Atualmente as informações consumidas, gerenciadas e produzidas pelosprocessos de negócios são os principais ativos organizacionais. Neste cenário, ainformação tornou-se o recurso estratégico de mais alto valor para asorganizações.Este caráter estratégico das informações posiciona os serviços de Tecnologia daInformação em uma posição estratégica nas organizações, pois estes serviçossão responsáveis pela coleta, análise, produção e distribuição das informaçõesrelevantes para a organização.De forma oportuna, serviço é definido como um meio para entregar valor aosclientes, propiciando os resultados que eles queiram alcançar sem que elestenham que assumir custos e riscos específicos. O valor de um serviço pode serdefinido em termos da percepção do cliente sobre os resultados obtidos a partirda utilização dos serviços (OGC, 2007).Embora as necessidades tecnológicas dos órgãos públicos sejam ilimitadas, osrecursos de TI são finitos e insuficientes para fazer frente às demandas. Entre osrecursos identificados no Control Objectives for Information and RelatedTechnology, os aplicativos são aqueles com maior influência na percepção devalor de TI (ITGI, 2007).Em geral, as particularidades dos processos de negócios demandam odesenvolvimento de aplicativos sob encomenda. A produção desse tipo deaplicativo é limitada pela disponibilidade de profissionais na área de TI dosórgãos e pela quantidade de aplicativos em fase de manutenção.Adicionalmente, há vários anos, os órgãos públicos têm adotado a prática daexecução indireta de muitos dos serviços que dão suporte às suas áreas-fim,conhecida como “terceirização de serviços”. O Decreto-Lei 200/1967 traz no seuart. 10, § 7ºi, a diretriz para que a Administração Pública Federal (APF) sedesobrigue da realização de tarefas executivas (execução de tarefasoperacionais), recorrendo, sempre que possível, à execução indireta, desde quea iniciativa privada esteja suficientemente desenvolvida na área, bem como nãohaja comprometimento da segurança nacional. De acordo com o Decreto-Lei200/1967, art. 10, § 7º, as razões para decisão favorável a execução indireta são(BRASIL, 2011i): • Possibilitar que a APF execute melhor as tarefas de planejamento, coordenação, supervisão e controle, tarefas que hoje podem ser traduzidas como gestão e governança; • Impedir o crescimento desmesurado da máquina administrativa, de modo que o Estado não alcance dimensão indevida em função da incorporação de tarefas de caráter operacional.O art. 1º do Decreto 2.271/1997 incluiu as atividades de informática no rol deserviços que devem ser preferencialmente objeto de execução indireta.
  • 4. Posteriormente, a IN 4/2008 – SLTI/MPOG (BRASIL, 2010d) regulamentou aterceirização de serviços de TI, considerando a legislação (e.g. Leis 8.666/1993e 10.520/2002) e jurisprudência corrente do Tribunal de Contas da União (TCU)sobre o assunto.Durante anos a execução indireta dos serviços de desenvolvimento emanutenção de software foi realizada na forma de postos de trabalho ou BodyShopping. Este é tipo de contratação em que o órgão contrata um conjunto deprofissionais para executar algum tipo de atividade, sem, entretanto, definirclaramente diversos elementos essenciais de contratação, como: a forma deexecução dos serviços, os produtos e serviços que devem ser entregues, oscritérios de qualidade para avaliação dos produtos e serviços entregues, níveismínimos de serviço exigidos, forma de acompanhamento dos serviços e sançõesespecíficas para a contratação. A responsabilidade de gerar resultados recaíasomente sobre o órgão, não sobre a contratada (BRASIL, 2011i).Contudo, a jurisprudência vigente do TCU condena o Paradoxo lucro-incompetência. Este termo foi apresentado no Acórdão 1.558/2003-TCU-Plenário para descrever o cenário no qual quanto menor a qualificação dosprestadores, maior é o número de horas necessárias para executar o serviço, demodo que o custo para a Administração torna-se maior e, desse modo, maior é olucro da empresa contratada em contratos por remuneração por hora trabalhada.Com esta restrição em foco, desde 2008 a jurisprudência do TCU e a IN 4/2008– SLTI/MPOG determinam que os órgãos públicos definam a forma de execuçãodos serviços, sendo preferencial a execução indireta, com medição porresultados e vincule os pagamentos a produtos e serviços entregues. Logo,cresceu desde então a opção e intenção dos órgãos públicos pela contrataçãode serviços de desenvolvimento de aplicativos no modelo conhecido como“Fábrica de Software”, um modelo, infelizmente, pouco conhecido eexperimentado com sucesso pela APF.Entretanto, para obter os objetivos e benefícios desse tipo de contratação, deve-se entender e gerenciar os riscos, desafios e requisitos legais atinentes.O processo de contratação de serviços, dentre os processos de TI, cujaconformidade legal deve ser controlada, deve ser destacada, pois (ITGI, 2005): 1. Trata-se de uma opção estratégica da área de TI; 2. Afeta diretamente a qualidade dos serviços de TI oferecidos aos clientes; 3. A área de TI continua a ser responsável pelos resultados dos serviços contratados; 4. Afeta os custos da área de TI e, portanto, o valor agregado à organização; e 5. Expõe a organização pública a muitos riscos adicionais, como (CRUZ, 2011): 5.1. Segurança da informação; 5.2. Dependência do fornecedor; 5.3. Descumprimento da legislação de licitações e contratos; 5.4. Descontinuidade tecnológica; 5.5. Dificuldade com a definição do escopo dos serviços; 5.6. Falta de compreensão do negócio pelos contratados; 5.7. Dificuldade em manter a qualidade dos serviços; 5.8. Perda do domínio do conhecimento de negócio; 5.9. Perda do controle da informação de negócio;
  • 5. 5.10. Perda de política interna de incentivo aos servidores; 5.11. Disputas entre equipes internas e de terceiros; 5.12. Problemas com diferenças de rendimentos; 5.13. Dificuldade em manter os padrões internos; 5.14. Risco de desequilíbrio financeiro do contrato; 5.15. Perda de controle dos custos do contratoRecentes auditorias do TCU revelaram, em diversos órgãos públicos federais,vários problemas relacionados a estes riscos. Assim, é requerida uma melhorcompreensão, por parte dos envolvidos, do modelo de terceirização na forma deFábrica de Software.Esse artigo tem como propósito apresentar as principais recomendaçõesrelacionadas à contratação de Fábrica de Software, desde a fase deplanejamento da contratação à gestão contratual. Os aspectos técnicos dacontratação relacionados à Engenharia de Software não foram abordados nesteartigo.Este trabalho encontra-se organizado da seguinte maneira: a Seção 1 descreveo cenário de contratação de serviços de fábrica de software e o objetivo desteartigo; a Seção 2 apresenta uma visão geral do modelo de Fábrica de Software;a Seção 3 identifica as principais recomendações em contratos de Fábrica deSoftware; Finalmente, a Seção 4 conclui o artigo.2 UMA VISÃO GERAL DO MODELO DE FÁBRICA DE SOFTWAREO termo Fábrica de Software (em inglês, Software Factory) foi empregado pelaprimeira vez em 1969, pela japonesa Hitachi, mas só começou a ficar popular noinício dos anos 90. A ideia era aplicar conceitos da indústria em geral emambientes de desenvolvimento de software, de forma a aumentar aprodutividade e diminuir prazos e custos.Fábrica de Software (FERNANDES, 2004) pode ser definida como “um processoestruturado, controlado e melhorado de forma contínua, considerandoabordagens de engenharia industrial, orientado para o atendimento a múltiplasdemandas de natureza e escopo distintas, visando à geração de produtos desoftware, conforme os requerimentos documentados dos usuários e/ou cliente,da forma mais produtiva e econômica possível”.A figura seguinte apresenta os escopos dos modelos de Fábrica, de acordo comFernandes (2004). Figura 01 – Escopo de fornecimento da Fábrica de Software (FERNANDES, 2004)
  • 6. As figuras seguintes apresentam um modelo genérico e os principaiscomponentes de uma Fábrica de Software (FERNANDES, 2004). Figura 02 – Modelo Genérico de Fábrica de Software (FERNANDES, 2004) Figura 03 – Principais Componentes de Fábrica de Software (FERNANDES, 2004)São requisitos para uma Fábrica de Software, ainda segundo Fernandes (2004): • Deve haver um processo definido e um padrão para o desenvolvimento do produto de software;
  • 7. • A Fábrica deve ter um forte gerenciamento da “interface” com o usuário e/ou cliente, tanto no sentido de recebimento de solicitações como de entrega dos produtos solicitados;• A entrada para a Fábrica (a Ordem de Serviço ou Solicitação de Serviço) deve ser padronizada;• As estimativas de prazo e custo devem ser baseadas na capacidade real de atendimento da Fábrica a uma determinada demanda;• Deve haver métodos padrões de estimativas baseados em históricos;• A Fábrica deve ter, de preferência, tempos padrões de atendimento já estabelecidos de acordo com o domínio da aplicação, da plataforma tecnológica e do tamanho da demanda (programa e/ou projeto);• Os perfis de recursos humanos devem ser controlados e estarem alinhados ao tipo de demanda (natureza e complexidade) da Fábrica;• A Fábrica deve ter um rigoroso controle dos recursos em termos de sua alocação, disponibilidade, necessidade futura e produtividade (esta deve ser medida);• A Fábrica deve ter um processo para o planejamento e controle da produção;• A Fábrica deve ter o controle do status das múltiplas demandas em seu processo e permitir rastreamento dessas demandas;• A Fábrica deve controlar todos os itens de software (documentos, métodos, procedimentos, ferramentas e código), criando uma biblioteca de itens;• A Fábrica deve ter o absoluto controle do andamento da execução de cada demanda;• Os produtos de software devem ser construídos de acordo com métodos, técnicas e ferramentas padronizadas;• A Fábrica pode ter processos distintos para atendimento a demandas de natureza diferentes;• Todos os recursos humanos devem estar aptos e treinados para as tarefas de desenvolvimento de software e para operarem processos operacionais e de gestão;• A Fábrica deve ter processos de atendimento (resolução de problemas) para os usuários e/ou clientes;• A Fábrica deve ter mecanismos que garantam a qualidade do produto de software, conforme requerimentos do usuário e/ou cliente;• A Fábrica dever ter mecanismos de apuração, apropriação e controle de custos;• A Fábrica deve ter mecanismos de medições de atributos de sua operação, tais como: tempos médios de atendimento, densidade de defeitos dos produtos, eficiência de remoção de defeitos, exatidão das estimativas e assim sucessivamente;• A Fábrica tem que ter um absoluto controle sobre os níveis de serviços acordados com os seus usuários e/ou clientes;• A Fábrica tem que melhorar seus processos de forma contínua, visando o aumento de sua produtividade e a redução de seus custos de operação; e• O ambiente de “hardware e software” da Fábrica deve ser estável e estar alinhado com as necessidades dos seus usuários e/ou clientes.
  • 8. 3 PRINCIPAIS RECOMENDAÇÕES EM CONTRATOS DE FÁBRICA DE SOFTWAREAs subseções seguintes apresentam diversos aspectos e recomendaçõesrelacionadas à contratação de Fábrica de Software. Esta seleção derecomendações foi baseada na experiência e nos estudos do Tribunal SuperiorEleitoral (TSE) neste tipo de contratação.3.1 PLANEJAMENTO DA CONTRATAÇÃOPara que a contratação de serviços de desenvolvimento de softwares no modelode Fábrica de Software agregue valor ao órgão contratante, com a consecuçãodos objetivos da contratação e dos benefícios esperados, é fundamental arealização cuidadosa, sistemática e criteriosa do planejamento da contração.Esta atividade visa identificar e gerenciar os riscos envolvidos inerentes aoobjeto e tipo de contratação, alinhar o contrato aos planejamentos estratégicosdo órgão e de sua área de TI, e garantir que os recursos, não apenas osfinanceiros, mas, principalmente, os humanos, sejam bem utilizados.O art. 4º da Instrução Normativa (IN) 4/2010 da SLTI/MPOG (Secretaria deLogística e Tecnologia da Informação/ Ministério do Planejamento, Orçamento eGestão) descreve que as contratações de TI deverão ser precedidas deplanejamento, elaborado em harmonia com o Plano Diretor de Tecnologia daInformação (PDTI), que, por sua vez, deverá estar alinhado com o planejamentoestratégico do órgão (BRASIL, 2010d). Destaca-se que esta IN possui efeitonormativo apenas para o Poder Executivo Federal.O planejamento é um princípio fundamental que deve estar presente em todaatuação da Administração Pública Federal, como descrito no Decreto-Lei200/1967, art. 6º, inciso I, e art. 10, § 7º. (BRASIL, 1967).O planejamento de contratação de serviços de desenvolvimento de softwares éimportante porque estas contratações (BRASIL,2011i): • Suportam cada vez mais as ações dos órgãos para que estes cumpram suas missões institucionais e alcancem seus objetivos estratégicos por meio dos serviços fornecidos pelos softwares objetos da contratação; • Afetam o mercado brasileiro produtor de softwares, logo os órgãos devem contratar Fábricas de Softwares considerando o incentivo ao mercado de software sob encomenda; • Envolvem grandes quantidades de recursos financeiros. Um levantamento recente do TCU mostrou que o orçamento de gastos em TI da Administração Pública Federal para 2010 era de pelo menos R$ 12,5 bilhões, sendo parte significativa desse orçamento dirigido para a contratação de serviços relacionados a software (CRUZ, 2011); • Deficiências no planejamento resultam em problemas na execução contratual; • Envolvem riscos operacionais para o órgão (e.g. se a empresa contratada para construir, todo ou parte, um software crítico para o órgão passar por dificuldade, de qualquer natureza, que a impeça de cumprir os termos contratuais, o órgão poderá deixar de prestar serviços importantes para a sociedade); • Demandam esforços consideráveis de várias unidades funcionais de cada órgão público para realização da licitação e respectiva gestão contratual (e.g. estudos técnicos preliminares, termo de referência, edital de
  • 9. licitação, análises jurídicas, contrato, recebimentos provisórios e definitivos, prorrogações, repactuações e aplicações de sanções); • Demandam esforços de várias unidades funcionais de cada órgão para colocar em operação o software produzido pela contratada, em especial da unidade que solicitou o software, da unidade de TI e dos usuários finais afetados, que podem abranger todos os servidores do órgão no caso de softwares corporativos (e.g. softwares de acompanhamento processual); • Demandam uma compreensão de um grande conjunto de dispositivos legais e jurisprudenciais por parte dos diversos envolvidos nas contratações, implicando investimento expressivo da Administração Pública para que os servidores incorporem esse conhecimento (e.g. mediante treinamentos e eventos) e o utilize nos processos de trabalho de contratação e de gestão contratual;3.2 PLANEJAMENTO DO ÓRGÃO E DE SUA ÁREA DE TIAcórdãos do TCU e a IN 4/2010 da SLTI/MPOG descrevem que as contrataçõesde TI deverão ser precedidas de planejamento, elaborado em harmonia com oPDTI, alinhado à estratégia do órgão ou entidade.O alinhamento estratégico é necessário para evitar que os recursos utilizados nacontratação não sejam desperdiçados em um contrato que não estejacontribuindo para a consecução dos objetivos estratégicos do órgão. Portanto,além de ser necessário o planejamento da contratação, seus planos devemestar alinhados com os planos organizacionais do órgão e da área de TI.Não obstante, no planejamento estratégico do órgão ou da área de TI, ou aindaem seus planos desdobrados, poderão existir softwares vinculados a objetivosestratégicos que possuem a intenção de encaminhamento para Fábrica deSoftware contratada para que esta realize serviços de desenvolvimento oumanutenção desses softwares. A utilização deste tipo de contrato para construirou alterar recursos estratégicos, neste caso, software, aumenta a relevância detipo de contrato.Como citado anteriormente, existem riscos operacionais para o órgão (e.g. se afábrica de software passar por dificuldade de qualquer natureza que a impeça decumprir os termos contratuais, o órgão poderá ter maiores dificuldades alcançaros objetivos de projetos ou organizacionais) inerentes à natureza do contrato deFábrica de Software, ao próprio objeto contratado e à maturidade organizacionaldas partes contratuais.Logo, a decisão de quais projetos de softwares estratégicos serão realizados,integral ou parcialmente, pela Fábrica de Software contratada deve sercuidadosamente analisada, com base em risco contratuais, administrativos,técnicos e políticos.Também é recomendado incluir no planejamento estratégico ou tático da áreade TI a contratação da Fábrica e a avaliação e melhoria da maturidade doscontroles dos processos de gestão contratuais, administrativos e técnicosnecessários para que esta contratação tenha êxito.O modelo de Gottfredson pode ser adaptado para apoiar a decisão de quaisprojetos de softwares serão realizados pela Fábrica de Software contratada. Omodelo original estabelece duas dimensões que influenciam a caracterização deum processo ou função empresarial para determinar o potencial retorno quepode se obter com a terceirização. A propriedade do processo ou função é uma
  • 10. das variáveis a ser considerada; por outro lado, a caracterização do processo oufunção quanto a ser específico do negócio ou comum no mercado, definem asegunda variável. A análise combinada da natureza do processo ou função e dograu de especificidade para o negócio aponta três classificações que podemorientar o processo decisório sobre terceirização (LAURINDO, 2006).De forma similar, o modelo pode ser aplicado para decidir quais projetos desoftware podem ser atendidos por contratos de Fábricas de Software,dependendo da análise de cada um dos sistemas do órgão público. Os sistemascomuns de mercado e que consequentemente não foram desenvolvidos noórgão e, portanto, não são proprietários, detêm a melhor possibilidade de êxitode serem desenvolvidos e mantidos numa Fábrica contratada. Os sistemasdesenvolvidos dentro da organização e que atendem necessidades muitoespecificas do negócio, não apresentam nenhuma atratividade para aterceirização numa fábrica de software, pois dificilmente um fornecedor poderiaoferecer melhores serviços com ganho de escala e sem depender dos própriosprofissionais que construíram o sistema. Além disso, é nesses sistemas querecai a foco principal de competência da área de TI do órgão público e atotalidade de sua capacidade interna de desenvolvimento de software deve serdepositada nestes tipos de sistemas para que órgãos cumpram suas missõesinstitucionais e alcancem seus objetivos estratégicos. Figura 04 – Modelo decisório sobre terceirização (LARINDO, 2006)3.3 RECURSOS HUMANOS NECESSÁRIOS A GESTÃO CONTRATUALErroneamente alguns pensam que quando uma organização de TI não possuimais capacidade operacional disponível para produção ou manutenção desoftware, a solução mais simples seria contratar um prestador de serviços paraampliar esta capacidade.
  • 11. No entanto, ao contrário da contratação de serviços por postos de trabalho, oesforço de gestão contratual de uma Fábrica de Software é bastante alto ecomplexo.O impacto de uma Fábrica de Software na área de TI está relacionado aogrande esforço com emissão contínua de Ordens de Serviço (OS), pois, além daelaboração desses artefatos, os produtos e serviços entregues têm que seravaliados com base nas especificações da OS e nos critérios de qualidade eprazo estabelecidos no contrato. Desse modo, a área de TI deve destacarservidores qualificados em gestão contratual, processos, métricas de softwares eno software em desenvolvimento para atuarem como fiscais do contrato e comomembros da comissão de recebimento provisório e definitivo, comprometendoparte dos recursos humanos da área de TI na atividade de gestão contratual.Assim como na área de TI do órgão público contratante, uma Fábrica deSoftware pode demandar grande esforço nas áreas requisitantes dos softwarescom relação ao uso de ordens de serviço, pois, além da participação da árearequisitante na elaboração dos artefatos de especificações dos requisitos dossoftwares, os produtos e serviços entregues têm que ser avaliados sob a óticada aderência aos requisitos de negócio estabelecidos. Desse modo, a árearequisitante deve destacar servidores devidamente qualificados nos processosde negócio suportados pelos softwares, em construção pela Fábrica, paraparticiparem do esforço de gestão contratual, comprometendo parte dosrecursos humanos da área requisitante nesse processo de trabalho.Adicionalmente, a área requisitante terá que indicar e definir quais alteraçõesdeverão ser feitas no software ao longo da vigência do contrato, bem como suaprioridade, e também tirar dúvidas dos usuários relativas às regras de negóciodo software (como a solução deve funcionar em termos de negócio) que nãoforem resolvidas no âmbito de um Service Desk (BRASIL, 2011i).Neste cenário, existe o risco da área requisitante do software argumentar que oesforço esperado dela é muito alto. Logo, a alta administração e a área de TIdevem conscientizar os gestores e colaborares da área requisitante a respeitoda importância da participação deles nas especificações dos softwares, bemcomo na avaliação dos serviços e produtos entregues, sob a perspectiva deatendimento da necessidade de negócio.Com já citado é requerida uma compreensão de um grande conjunto dedispositivos legais e jurisprudenciais por parte dos diversos envolvidos nacontratação da Fábrica de Software. Além disso, também é necessárioconsiderar os regulamentos internos ao órgão (e.g. política de segurança dainformação - PSI) e a legislação e jurisprudência específicas sobre os processosde negócio que a software deverá apoiar.Para executar adequadamente as atividades relativas à contratação de Fábricade Software e à gestão do contrato decorrente, inclusive as de caráterestruturante, o órgão tem que contar com quantidade de servidores (pessoas)compatível com a carga de trabalho gerada por essas atividades. Adisponibilidade de pessoal para planejar a contratação e posteriormente efetuara gestão contratual deve, inclusive, ser considerada como fator de risco naavaliação da viabilidade da contratação (BRASIL, 2011i).Portanto, o órgão público e sua área de TI deverão ter servidores capacitadospara atender este demanda gerencial para a contratação alcançar os resultadospretendidos. Ou seja, no caso da ausência de capacidade operacional esgotada,
  • 12. a solução da contratação de um Fábrica de Software demandará o uso de umacapacidade gerencial especializada, que provavelmente o órgão não possuirádisponível.3.4 ESTUDOS TÉCNICOS PRELIMINARESOs termos de referência ou projetos básicos são derivados dos estudos técnicospreliminares. O inciso IX do art. 6º da Lei 8.666/1993 afirma que o projeto básicoé elaborado com base nas indicações dos estudos técnicos preliminares, queassegurem a viabilidade técnica e o adequado tratamento do impacto ambientaldo empreendimento. No cenário de contratação de Fábrica de Software, oambiente impactado é o ambiente de TI e de negócio do órgão.Logo, a elaboração dos estudos técnicos preliminares é a primeira etapa doplanejamento de uma contratação. Sem estes estudos técnicos preliminares,existe o alto risco de o órgão consumir recursos financeiros, esforçoadministrativo e tempo para efetuar a elaboração do termo de referência ou doprojeto básico de baixa qualidade, que resultará em uma licitação e gestãocontratual infrutíferas, cuja inviabilidade poderia ter sido verificada na primeiraetapa do planejamento da contratação.A IN 4/2010 – SLTI/MPOG (BRASIL, 2010d) estabelece que a fase deplanejamento da contratação consiste na elaboração dos documentos (art. 9º,caput, art. 10ºxxv): Oficialização da Demanda, Análise de Viabilidade, Plano deSustentação, Estratégia de Contratação, Análise de Riscos e Termo deReferência ou Projeto Básico.Nesta Instrução Normativa, os estudos técnicos preliminares e a análise deviabilidade da contratação são realizados na elaboração dos documentos“Oficialização da Demanda” e “Análise de Viabilidade”.O processo de Análise de Viabilidade da Contratação na IN 4/2010 –SLTI/MPOG possui nove atividades seguintes e produz o documento Análise deViabilidade da Contratação: 1) Definir Requisitos; 2) Especificar Requisitos; 3) Identificar Soluções; 4) Avaliar Soluções; 5) Escolher Solução; 6) Justificar Solução Escolhida; 7) Avaliar Necessidades de Adequação; 8) Consolidar Informações; e 9) Aprovar Análise de Viabilidade.Este documento, de acordo com IN 4/2010 – SLTI/MPOG, contém as seguintesinformações: 1. Descrição da Solução de Tecnologia da Informação; 2. Requisitos de Negócio da Área Requisitante; 2.1. Necessidades de Negócio; 2.2. Demais Requisitos: Requisitos de Capacitação, legais, de manutenção, temporais, de segurança, Sociais, Ambientais e Culturais. 3. Levantamento das Alternativas; 4. Detalhamento das Alternativas Existentes; 5. Justificativa da Solução Escolhida; 6. Necessidades de Adequação do Ambiente para Execução Contratual;
  • 13. O outro documento citado anteriormente, “Oficialização da Demanda”, formalizao início do processo de planejamento da contratação de TI e vincula asnecessidades da contratação desejada aos objetivos estratégicos e àsnecessidades corporativas da instituição.3.5 PROCESSO DE SOFTWAREO planejamento da contratação de uma Fábrica de Software deve definirclaramente os critérios de qualidade e conformidade a serem verificados nosprodutos e serviços entregues. Estes critérios são, em geral, derivados doprocesso definido de software do órgão público contratante.Processo é uma coleção de atividades, ações e tarefas que são realizadasquando algum produto de trabalho é criado. No contexto de engenharia desoftware, um processo não é uma prescrição rígida de como criar um softwareaplicativo. Pelo contrário, processo de software é uma abordagem flexível quepermite que as pessoas que fazem o trabalho (a equipe de software) escolhamum conjunto de ações adequadas de trabalho e tarefas. A intenção é sempreentregar software em tempo hábil e com qualidade suficiente para satisfazeraqueles que têm patrocinado a sua criação e aqueles que vão usá-lo(PRESSMAN, 2010). Sommervile (2007) define um processo de software comoum o conjunto de atividades e resultados associados que produzem um produtode software.A estrutura do processo de software estabelece a fundação para um processocompleto de engenharia de software, identificando um pequeno número deatividades que são aplicáveis a todos os projetos de software,independentemente do seu tamanho ou complexidade. Além disso, a estruturade processo engloba um conjunto de atividades guarda-chuva que sãoaplicáveis em todo o processo de software (PRESSMAN, 2010).Um modelo de processo de software é uma descrição simplificada de umprocesso de software que apresenta uma visão desse processo. Modelos deprocessos podem incluir atividades que fazem parte do processo de software,produtos de software e os papéis das pessoas envolvidas em engenharia desoftware (SOMMERVILE, 2007).Existem quatro atividades fundamentais de processo que são comuns a todos osprocessos de software (SOMMERVILE, 2007). Estas são: • Especificação de software onde os clientes e engenheiros definem o software a ser produzido e as restrições sobre o seu funcionamento. • Desenvolvimento de software onde o software é projetado e programado. • Validação de software onde o software é verificado para garantir que ele atenda as necessidades definidas do cliente. • Evolução do software onde o software é modificado para adaptá-lo aos novos requisitos dos clientes e do mercado.O uso de um processo de software inadequado pode reduzir a qualidade ou autilidade do produto de software a ser desenvolvido e/ou aumentar os custos dedesenvolvimento (SOMMERVILE, 2007).Para garantir a qualidade dos produtos e serviços de software, destaca-se,dentre os processos fundamentais, o processo padrão de desenvolvimento desoftware, que estabelece seu ciclo de vida e os processos de gestão comogerência de projetos, gerência de requisitos, gerência de configuração, garantiada qualidade, medição, verificação, validação. Estes são alguns dos processosdo modelo de maturidade de processo de software MPS.BR (Melhoria de
  • 14. Processos do Software Brasileiro). A maioria destes processos citados estárelacionada aos níveis de maturidade G (Parcialmente Gerenciado) e F(Gerenciado) desse modelo (CRUZ, 2011).Com foco primário na avaliação de controles gerais de Tecnologia da Informaçãonos órgãos público federais, em 2010 e 2011, o TCU detectou, por meio deauditorias de governança de TI, em diversos órgãos jurisdicionados umaconsiderável frequência de irregularidades relacionadas à inexistência,deficiências e a falhas de processos de softwares (BRASIL, 2011a, 2011b,2011c, 2011d, 2011e, 2011f, 2011g, 2011h, 2010a, 2010b, 2010c), quecomprometem a eficácia, eficiência e economicidades das contratações dedesenvolvimento de sistemas.Para a inexistência e falha de processos de softwares, o TCU listou comoefeitos/consequências: • Deficiência no processo de contratação, decorrente da inexistência de metodologia que assegure boa contratação de desenvolvimento de sistemas. (efeito real) • Inexistência de parâmetros de aferição de qualidade para contratação de desenvolvimento de sistemas. (efeito real)Para a deficiência de processos de softwares, o TCU listou comoefeitos/consequências: • Processo de desenvolvimento de sistemas lento e sistemas de informação ineficazes. (efeito potencial) • 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) • 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) • 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)Para estas irregularidades, relacionadas aos processos de software, o TCUrecorrentemente recomenda, nas propostas de encaminhamento dos relatóriosde auditorias, com fulcro na Lei nº 8.443/1992, art. 43, inciso I, que os órgãosauditados: • 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. Critérios relevantes para esta definição, indicados pelo TCU: Lei nº 8.666/1993, art. 6º, inc. IX; Resolução nº 90/2009, do CNJ, art. 10; Instrução Normativa nº 04/2008 - SLTI/MPOG, art. 12, II; Normas Técnicas - ITGI - Cobit 4.1, PO8.3 - Padrões de desenvolvimento e de aquisições; NBR ISO/IEC - 12.207; NBR ISO/IEC 15.504; • 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.
  • 15. • 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;Em auditoria na Agência Nacional de Telecomunicações – Anatel (Brasil,2011d), o TCU constatou que a Anatel possuía um nível decapacidade/maturidade de processo de desenvolvimento de softwaregerenciado, no entanto, embora este processo possuísse os elementosessenciais definidos na matriz de planejamento da fiscalização do TCU, oprocesso ainda carecia de aprovação e publicação, com vistas a assegurar aaderência das rotinas de trabalho da área de TI da Agência ao processo por eladefinido. Esta falta de aderência esta relacionada à deficiência deinstitucionalização do processo de software, que dependem diretamente daaprovação e patrocínio do processo por parte da alta administração, seja de TIou de negócio.O CMMI (Capability Maturity Model Integration), modelo de maturidade paradesenvolvimento de software do SEI (Software Engeneering Institute – CarnegieMellon University – EUA) descreve as seguintes práticas para se alcançar ainstitucionalização de um processo definido (SEI, 2010): 1. Estabelecer e manter uma política organizacional para planejamento e execução do processo; 2. Estabelecer e manter o plano para a execução do processo; 3. Fornecer recursos adequados para a execução do processo; 4. Atribuir responsabilidade e autoridade pela execução do processo, elaboração dos produtos de trabalho e fornecimento de serviços do processo; 5. Treinar as pessoas para executar ou dar suporte ao processo; 6. Colocar os produtos de trabalho projetados do processo sob níveis apropriados de controle; 7. Identificar e envolver os principais envolvidos (stakeholders) relevantes do processo; 8. Monitorar e controlar o processo com relação ao plano de execução do processo e tomar ações corretivas apropriadas; 9. Avaliar objetivamente a aderência do processo com relação à sua descrição, padrões, procedimentos e encaminhar as não-conformidades para serem tratadas. 10. Revisar as atividades, a situação e os resultados do processo a gerência superior e solucionar problemas; 11. Estabelecer e manter a descrição de um processo definido; Coletar produtos de trabalho, medidas, resultados de medições e informações de melhoria derivadas do planejamento e da execução do processo para dar suporte ao uso futuro e à melhoria dos processos e ativos de processo da organização.Pela análise destas práticas, pode-se inferir que os esforços, custos,comprometimento e tempo para institucionalizar um processo definido são altos.Em organizações públicas sem fins lucrativos, cuja missão institucional nãoesteja diretamente relacionada à produção de softwares, os esforçosnecessários para institucionalização de um processo definido de softwares sãomaiores devido aos processos de TI serem processos organizacionais desuporte, com alta probabilidade de serem preteridos em questões de
  • 16. investimento e patrocínio quanto estes competem com os processosorganizacionais primários ou essenciais.Ainda relacionado à aprovação do processo de software, o TCU constatou emauditoria no Ministério da Saúde que o processo de software do órgão tambémnão tinha sido aprovado e publicado oficialmente para uso no órgão, bem comoele apresentava falhas na definição dos papéis e responsabilidades (Brasil,2011f).Acrescenta-se ainda que o gestor de TI deste órgão público, quandoquestionado acerca da ausência nos documentos de requisitos das assinaturasdos responsáveis envolvidos, o que corresponde ao registro de aceite, afirmouque parte dos requisitos produzidos pelo processo de software não sãoassinados pelos clientes, em virtude da dificuldade em obter essas assinaturasdevido à cultura do local.Em auditoria realizada no Ministério das Relações Exteriores, o TCU (Brasil,2011g) constatou que embora este órgão possuísse uma metodologia dedesenvolvimento de software, não ficou comprovada sua aplicabilidade,desrespeitando o art. 6º, inc. IX, da Lei 8.666/93 e o art. 12, II, da IN 04/2008 -SLTI/MPOG. Esta irregularidade também está relacionada à deficiência deinstitucionalização do processo de software e provavelmente também a um altograu de diferença (“gap”) entre a maturidade real do processo na organização ematuridade pretendida, aquela apresentada e definida na metodologia.Deve ser destacado que os esforços para a obtenção dos primeiros níveis dematuridade, tanto do modelo CMMI quanto do MPS.BR, são os maiores dentreos níveis prescritos nestes modelos devido à necessidade de gerenciar amudança de cultura organizacional, provocada pela introdução na organizaçãode TI de dois elementos estruturais: organização por processos e orientação aprojetos.No relatório de auditoria no TRT/2ª Região, TCU menciona que todo órgão ouentidade deve adotar metodologia de desenvolvimento de software queassegure a boa contratação de desenvolvimento de sistemas e de parâmetrosde aferição de qualidade para essa contratação, de modo a assegurar níveismínimos de padronização e segurança (Brasil, 2010b). O TCU também afirmaque em razão da inexistência de processo de desenvolvimento de softwareinstitucionalizado, aprovado e publicado no âmbito do órgão auditado, toda equalquer contratação para desenvolvimento de sistemas apresentará falhasinsanáveis, ante o vício na origem. Ressaltou-se que a falta de domínio doprocesso fragiliza o órgão, que acaba por ter que se submeter aos critériosdefinidos pelas contratadas.Portanto, a definição e implantação de um processo de software, com a previsãodos artefatos a serem produzidos neste processo, é indispensável para que sepossa realizar uma contratação de empresa prestadora de serviços dedesenvolvimento de software (Lei 8.666/93, art, 6º, inciso IX) (Brasil, 2011e). Noentanto, a adoção de processos é necessária tanto pelo contratante como pelacontratada para ter garantia da qualidade dos serviços e produtos e minimizar osriscos da contratação (CRUZ, 2011).Frequentemente com desejo de selecionar o fornecedor com maior nível dematuridade de processos de software, que em teoria poderia significar menorrisco de baixa qualidade dos produtos de softwares entregues ao contratante,diversos órgãos cogitam a possibilidade de exigirem certificações oficiais de
  • 17. MPS.BR ou CMMI dos fornecedores, durante o processo licitatório namodalidade pregão, especialmente na forma eletrônica. Neste cenário licitatórionão se pode exigir do fornecedor estes tipos de certificação (CRUZ, 2011).Mesmo que a licitação seja dos tipos “técnica” e “técnica e preço”, também nãose pode exigir do fornecedor uma certificação de nível de maturidade superior aonível atual do contratante, pois este não obteria os benefícios decorrentes donível superior de maturidade do fornecedor. Nesta situação existe um cenário deocorrência de prejuízos financeiros devido ao alto custo cobrado pelo fornecedorrelacionado ao seu alto nível de maturidade do processo de software. Alémdisso, houve uma restrição injustificável de competitividade do certame licitatório.Ressalta-se que também que não é prudente definir um processo de softwarecom diversos controles de qualidade de produtos de trabalho que a organizaçãonão está habituada e capacitada em desempenhá-los, pois existirá uma altaprobabilidade do processo de garantia da qualidade dos produtos entregues,pela contratada, ser ineficiente e ineficaz, ou seja, resultará em esforçoscontraproducentes.Diante do exposto, registra-se como lição apreendida e recomendações: • Diante do alto custo de institucionalização de processos definidos, normalmente projetos de softwares realizados nas instalações do órgão público (in house), com servidores públicos ou com profissionais de um fornecedor, praticam parcialmente o processo definido. Por outro lado, por questões contratuais, as equipes de projetos de software da contratante que se relacionam com uma Fábrica de Software contratada apresentam melhores índices de aderência ao processo definido de software da organização pública. • No processo padrão de desenvolvimento de software, para garantir a qualidade dos produtos e serviços de software, especialmente no modelo Fábrica de Software, e que a contratação atinja seus objetivos e benefícios esperados, os processos abaixo, do modelo MPS.BR, devem possuem níveis adequados de capacidades: - Gerência de projetos (GPR); - Gerência de requisitos (GRE); - Desenvolvimento de requisitos (DRE), quando as atividades de requisitos são desempenhadas pela contratante e as etapas seguintes de desenvolvimento pela contratada; - Projeto e Construção do Produto (PCP), quando estas atividades são desempenhadas pela contratante e as etapas seguintes de desenvolvimento pela contratada; - Gerência de configuração (GCO); - Garantia da qualidade (GQA); - Medição (MED); - Verificação (VAL); - Validação (VER). • Os parâmetros de aferição de qualidade para contratação de desenvolvimento de sistemas devem ser, em regra, derivados dos critérios contidos no processo de softwares e principalmente devem ser simples, claros e objetivos. Assim não é recomendado definir no processo de software diversos controles de qualidade de produtos de trabalho que
  • 18. a organização não está habituada e capacitada em desempenhá-los, pois poderá resultar em esforços contraproducentes; • As métricas de aferição de qualidade dos produtos, além de terem as qualidades supracitadas para os parâmetros, devem ser poucas, baseadas nas necessidades de informação organizacionais e contratuais, e possuírem baixa complexidade e custo de medição. • As ações de melhoria do processo padrão de desenvolvimento de software devem considerar como referência os modelos e normas de melhorias de processos de softwares CMMI e MPS.BR, e os objetivos de controle de processo em normas técnicas de controle de TI; • O processo padrão de desenvolvimento de software deve ser aprovado por parte da alta administração, seja de TI ou de negócio, e amplamente publicado para as equipes que se relacionam com Fábrica de Software. • A falta de domínio do processo pelas equipes de projeto que se relacionam com um Fábrica de Software fragiliza o órgão, que acaba por ter que se submeter aos critérios definidos pelas contratadas. • Deve ser simples e aplicável o processo de software definido, com definição clara de papéis e responsabilidades, de modo a assegurar níveis mínimos de padronização e segurança. Logo, devido aos riscos inerentes da gestão de mudança de cultura organizacional deve-se evitar, principalmente quando se pretende alcançar os primeiros níveis de maturidade prescritas nos modelos CMMI e MPS.BR, um alto grau de diferença (“gap”) entre a maturidade real do processo na organização e maturidade pretendida, aquela definida e aprovada pela organização. • Não se deve exigir do fornecedor ou contratada um nível de maturidade superior ao nível real do órgão público ou aquele que esteja descrito em um plano aprovado de melhoria de maturidade. Neste cenário, o esforço de verificação aumentaria de forma desnecessária e inútil devido à necessidade de analisar e emitir julgamento de qualidade em produtos de trabalho intermediários dos projetos de software que a contratada não possui capacidade e maturidade de compreensão e tratamento. Logo, os benefícios esperados de determinado nível de maturidade da contratada não se realizariam e seriam contraproducentes. • O cliente da área de negócio, bem como a equipe de projetos da contratante, deve ser orientado e possuir uma compreensão clara de suas responsabilidades nos projetos de desenvolvimento, bem como dos momentos de participação no processo e no contrato. • A adoção de processos é necessária tanto pelo contratante como pela contratada para ter garantia da qualidade dos serviços e produtos e minimizar os riscos da contratação. Pode-se aceitar um processo de software da contratada compatível com o da organização pública contratante, no entanto, neste caso, poderão ocorrer problemas de divergências de formatos de produtos de trabalho e uso confuso de termos técnicos, devido principalmente a diferenças culturais organizacionais.3.6 MODELO DE EXECUÇÃO DO OBJETODurante a fase de planejamento da contratação deve ser elaborado um modelode execução do objeto que esteja de acordo com os objetivos contratuaispretendidos e que considere a cultura e maturidade organizacional, bem como,
  • 19. deve ter conformidade com legislação e da jurisprudência que se aplicam aqualquer contratação, e também aos regulamentos internos ao órgão.O contrato deverá produzir os resultados pretendidos, desde o seu início até oseu encerramento. No caso da contratação de serviços, o modelo de execuçãodo objeto é denominado “modelo de prestação de serviços” na jurisprudência doTCU e de “modelo de prestação de serviços ou de fornecimento de bens”, no art.17, § 1º, inciso V, da IN - SLTI 4/2010 (BRASIL, 2011i).Deve-se fixar a mensuração, sempre que possível, da prestação de serviços porresultados, segundo especificações previamente estabelecidas, evitando-se amera locação de mão-de-obra e o pagamento por hora-trabalhada ou por postode serviço. A metodologia utilizava deve ser expressamente definida no edital edeve contemplar, entre outros, os seguintes pontos básicos (BRASIL, 2010d): • A fixação dos procedimentos e dos critérios de mensuração dos serviços prestados, abrangendo métricas, indicadores, valores aceitáveis etc.; • A quantificação ou a estimativa prévia do volume de serviços demandados, para fins de comparação e controle; • A definição de metodologia de avaliação da adequação dos serviços às especificações, com vistas a aceitação e pagamento; • A utilização de um instrumento de controle, geralmente consolidado no documento denominado “ordem de serviço” ou “solicitação de serviço”; • A definição dos procedimentos de acompanhamento e fiscalização a serem realizados concomitantemente à execução para evitar distorções na aplicação dos critérios.Em suma, deve-se buscar a prestação de serviços pagos por produtos eserviços entregues. Esse modelo de prestação de serviços traz váriasvantagens, tais como (BRASIL, 2011i): • A vinculação do pagamento a produtos e serviços entregues, de modo que o órgão contratante não pague pelo esforço da contratada, e sim pelo que ela efetivamente entregar. Em outras palavras, o órgão não contrata um contingente de profissionais para fazer o que for demandado ao longo do tempo, correndo-se o risco dessas pessoas não fazerem trabalhos alinhados com os objetivos dos órgãos e da área de TI ou ficarem ociosas em parte significativa do tempo; • A contratada é responsável pela geração dos produtos e serviços contratados, de modo a buscar aderência aos critérios de qualidade estabelecidos no contrato, sob pena de não receber e de ser penalizada (e.g. ser multada ou ser declarada inidônea), diminuindo-se a probabilidade de ocorrência do paradoxo lucro-incompetência. • Há menor pessoalidade (dependência com relação a funcionários específicos da contratada) e menor ou nenhuma relação de subordinação entre o órgão e os profissionais da contratada (e.g. controle de horário, acordo com relação a períodos de férias e comandos para executar tarefas), pois o contato entre o órgão e a contratada ocorre essencialmente mediante o preposto da contratada, de modo que o órgão fica menos sujeito a enfrentar problemas trabalhistas.
  • 20. 3.7 ORDEM DE SERVIÇOOrdem de Serviço é o documento utilizado para solicitar à contratada aprestação de serviço ou fornecimento de bens relativos ao objeto do contrato(BRASIL,2010e).Este documento deve conter, entre outros aspectos quetambém possam vir a ser considerados necessários pelo órgão (BRASIL,2010d)(BRASIL, 2011i): a) Definição e a especificação dos serviços a serem realizados; b) Métricas utilizadas para avaliar o volume de serviços solicitados e realizados; c) Os produtos solicitados; d) Cronograma de realização do serviço, incluídas todas as tarefas significativas e seus respectivos prazos; e) Após a entrega dos produtos e serviços, a avaliação da qualidade e as justificativas do avaliador; f) Custos em que incorrerá o órgão para consecução do serviço solicitado; e g) Indicação clara do servidor responsável pela solicitação, bem como pela avaliação da qualidade e pela atestação dos serviços realizados, os quais não podem ter nenhum vínculo com a empresa contratada;Na publicação do edital, o modelo de Ordem de Serviço deve ser incluído, emobediência ao disposto no artigo 17, inciso V, e deve considerar para os camposdescritos nas alíneas do art. 20, inciso II, ambos da IN/SLTI n. 04/2010.Além disso, deve ser estipulado pelo órgão público o método ou processo peloqual as Ordens de Serviço são utilizadas como instrumento de controle nasetapas de solicitação, acompanhamento, avaliação, atestação e pagamento deserviços.A entrega dos produtos solicitados na Ordem de Serviço pode ser realizada deforma integral ou parcelada. Neste último caso, cada parcela deve especificar osprodutos solicitados, o volume de serviços solicitados, custos do serviçosolicitado, cronograma de realização e de entrega dos produtos. O modelo deOrdem de Serviço deve prever esta forma de recebimento parcelado do objetocontratado.Diante do exposto, registra-se como lição apreendida e recomendações: • 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; • Deve ser previsto no Modelo de Ordem de Serviço a possibilidade de entregas parceladas do objeto contratado. A organização das especificações relacionadas às entregas parceladas deve ser cuidadosamente definida no modelo, com fim de facilitar o acompanhamento da execução e posterior recebimento do objeto. • A Ordem de Serviço deve ser assinada pelo Gestor/Fiscal do Contrato. Recomenda-se antes da assinatura que as áreas de negócio, técnica e administrativa realizem verificações e validações das especificações e estimativas da demanda formalizada na Ordem de Serviço. Após a assinatura, o documento deve ser encaminhado formalmente ao preposto da contratada, que também deve subscrever o documento.
  • 21. 3.8 MEDIÇÕES DOS SERVIÇOSA jurisprudência do TCU e a IN - SLTI 4/2010 estabelecem que as contrataçõesde soluções de TI, como regra, sejam remuneradas por produtos e serviçosentregues, conforme critérios objetivos e claros estabelecidos no contrato. Aremuneração focada em resultado possibilita que o órgão vincule o pagamento aprodutos e serviços entregues ao invés de vinculá-la ao esforço da contratada. Oobjetivo é diminuir a probabilidade de ocorrência do paradoxo lucro-incompetência.A métrica de tamanho funcional de software chamada “Pontos de Função” (PF)normalmente é definida e utilizada em serviços de desenvolvimento de softwarespara estimar e mensurar o volume de serviços solicitados e realizados nasOrdens de Serviços.A técnica de Análise de Pontos de Função mede o software através daquantificação da funcionalidade que o software provê ao usuário, com baseprincipalmente no projeto lógico. Esta técnica pretende medir a funcionalidadeque o usuário solicita e recebe e medir o desenvolvimento e a manutenção desoftware, independentemente da tecnologia utilizada para implementação(IFPUG, 2004).A ampla adoção desta métrica em desenvolvimento e a manutenção de softwaredecorre do processo de contagem de ponto de função ser suficientementesimples para minimizar a sobrecarga no processo de medição e da métrica serusado de forma consistente entre os vários projetos e organizaçõesGeralmente em projetos de softwares, os esforços de desenvolvimento e amanutenção de software são distribuídos em percentuais do “Ponto de Função”.No entanto, quando esforço de algumas atividades relevantes não são passíveisde serem pontuadas pela técnica de Análise de Pontos de Função, adota-se achamada “Tabela de Itens Não Mensuráveis”.Logo, o tamanho do serviço em Pontos de Função corresponderá ao somatórioda quantidade total de Pontos de Função das funcionalidades relacionadas aoserviço contratado e da quantidade de Pontos de Função derivados dos itensnão-mensuráveis.As fases do processo de software do TSE e os percentuais abaixo se referem àdistribuição de esforços de desenvolvimento correspondente ao esforço daentrega de 1 (um) Ponto de Função para o usuário: Fases do Processo de Software Percentual de esforço do TSE Admissão 5% Formulação 20% Manufatura 55% Entrega 10% Atividades exclusivas do TSE 10% Tabela 01: Distribuição de esforços das fases do processo / 1 (um) Ponto de FunçãoComo o processo de software do TSE é derivado, dentre outros, do ProcessoUnificado de Desenvolvimento de Software (Unified Software DevelopmentProcess - USDP) foi utilizado como referência a distribuição de esforços nasfases do Processo Unificado da Rational/IBM. Fases do Processo Unificado da Percentual de esforço Rational/IBM
  • 22. Iniciação ~ 5% Elaboração 20% Construção 65% Transição 10% Tabela 02: Distribuição de esforços das fases do Processo Unificado da IBM/RationalRelacionado à fase Construção do Processo Unificado da Rational/IBM, a faseManufatura do Processo do TSE apresenta um valor menor devido ao númeroreduzido de atividades e controles presentes nesta fase quando comparada comaquela.O TSE entende que participa da entrega da funcionalidade que o usuário solicitanos softwares, logo foi acrescentado na distribuição dos esforços em Pontos deFunção as “Atividades exclusivas do TSE”, que correspondem às atividades deGarantia de Qualidade de Produtos e Processo.Estas atividades, pela relevância e pelas características, são realizadasexclusivamente pelo TSE ou empresa designada por ele, pois como o TSE faz ainspeção naqueles artefatos que são fundamentais para garantir a qualidade dossistemas, o órgão entende que tais atividades são de sua responsabilidade.Uma inovação que o TSE apresenta é a distribuição de esforços dedesenvolvimento em disciplinas do processo de software do órgão. Disciplinas de Desenvolvimento Percentual de esforço do Processo de Software do TSE Requisitos 15% Análise e Projeto 15% Implementação 30% Testes 25% Implantação 5% Atividades exclusivas do TSE 10% Tabela 03: Distribuição de esforços das disciplinas do processo / 1 (um) Ponto de FunçãoEm contratos de Fábrica de Software, as funções de dados AIE (ArquivosInterface Externa) dos softwares deverão ser contados, mas não remunerados,em regram, à contratada sempre que para sua inclusão, alteração ou exclusãoforem utilizados componentes, de qualquer tipo (e.g. scripts, classes, interfaces,procedimentos/funções de banco), fornecidos pelo órgão contratante, excetoquando seja comprovada tecnicamente pela Fábrica de Software junto ao órgãocontratante, a necessidade de esforço para extração dos dados dos AIE com autilização desses componentes.Esta regra é utilizada para evitar vários pagamentos indevidos relacionados aapenas uma funcionalidade do software, ou seja, uma funcionalidade dosoftware entregue deve ser paga apenas uma vez pela contratante.A técnica definida pela NESMA (Netherlands Software Metrics UsersAssociation) para contagem de Pontos de Função normalmente é utilizada nasatividades de estimativa e a técnica do IFPUG (International Function PointUsers Group) para atividades de mensuração dos serviços descritos nas Ordensde Serviço.Em Ordem de Serviços em que os projetos lógicos ou especificações detalhadasde requisitos não fazem parte dos insumos, realiza-se uma contagem inicialestimada devido à falta de informações. No entanto, as outras estimativas (e.g.
  • 23. cronograma de entrega dos produtos) relacionadas à execução do serviçoderivam dessa estimativa de Pontos de Função.No recebimento dos produtos deve ser realizada outra contagem, se possívelcom a técnica do IFPUG, para fins de pagamento. Quando há uma percepçãodas equipes de projeto durante a execução dos serviços de alto desvio, entreestimado e real, é recomendada a realização de outra contagem, acrescentandocomo insumo as novas informações obtidas após a contagem inicial naformalização da Ordem de Serviço.Recomenda-se que exista um profissional capacitado na técnica de Pontos deFunção, se possível com certificação CFPS (Certified Function Points Specialist)do IFPUG, para validar as estimativas e mensurações de tamanho funcional dasOrdens de Serviços. Neste caso, é essencial a segregação de funções, ou seja,quem realiza a contagem de Pontos de Função não deve ser quem valida àcontagem e autoriza os serviços. Onde for difícil a segregação de funções,convém que outros controles sejam considerados.No caso de ocorrência de divergência por parte da Fábrica de Software quantoàs contagens realizadas pelo órgão contratante, com efeitos financeiros, oTermo de Referência ou Projeto Básico deve estabelecer as regras de resoluçãodesta divergência no contrato.3.9 PRAZO DE ATENDIMENTO DOS SERVIÇOS PELA FÁBRICA DE SOFTWAREGeralmente o estabelecimento de prazos para atendimento dos serviços ébaseado na quantidade de Pontos de Função da Ordem de Serviço. No entanto,devido a condições relevantes ou supervenientes relacionados ao serviçodemandado, quando venham a interferir no andamento do serviço, prazossuperiores poderão ser excepcionalmente admitidos a critério do órgãocontratante.O prazo de cada serviço contratado deve ser formalizado na Ordem de Serviço.O descumprimento deste prazo sujeitará, sem motivo justificável, a Fábrica deSoftware a aplicação de penalidade contratual.Além desses prazos relacionados à execução dos serviços, também deve sercuidadosamente definido os prazos de correção de produtos e serviçosentregues com defeitos, durante o procedimento de recebimento do objeto ou degarantia do produto e serviço.3.10 PROTOCOLO DE COMUNICAÇÃO ENTRE CONTRATANTE E CONTRATADA AO LONGO DO CONTRATOOs contratos de Fábrica de Software são caracterizados pelo pagamentovinculado a produtos e serviços entregues e definição de requisitos e deelementos contratuais que impedem ou reduzem a ingerência do órgão públicosobre a administração da contratada, que poderia caracterizar terceirizaçãoilegal. Portanto, no modelo de execução do objeto deve ser definido que(BRASIL, 2011i): • Os funcionários da contratada somente devam trabalhar dentro das instalações do órgão se for estritamente necessário, com a devida justificativa; • A interação entre o órgão e a contratada ocorra essencialmente por intermédio do preposto, com exceção de serviços que exijam interação direta entre os profissionais do órgão e a contratada (e.g. especificação
  • 24. de requisitos de software), ou outros canais de atendimento (e.g. telefone, e-mail, fax, software de acompanhamento, helpdesk); • Aspectos relativos à relação contratual entre a contratada e seus funcionários (e.g. solicitação de férias e avaliação de desempenho individual) sejam tratados entre essas duas partes, sem interferência do órgão; • O Termo de Responsabilidade e Sigilo para acesso às informações e aos sistemas do órgão seja coletado pela contratada junto a cada funcionário seu e entregue ao órgão, de modo que não seja coletado diretamente pelo órgão junto a cada funcionário da contratada;3.11 FORMA DE PAGAMENTO DO SERVIÇONo contrato do TSE, os pagamentos das Ordens de Serviços são realizados emconformidade aos percentuais representativos do tamanho em pontos de função,determinados pelo percentual de esforço das fases ou disciplinas do processode software do órgão.Cada Ordem de Serviço deve indicar quais fases ou disciplinas são realizadaspela Fábrica de Software contratada. Não podem ser indicadas as duasdimensões simultaneamente, pois não foi realizada uma correspondência entreas duas, ou seja, pode-se escolher apenas uma dimensão: fase ou disciplina.Todas as Ordens de Serviços do projeto de software devem indicar a mesmadimensão, vedado a alteração posterior sob o risco de pagamento indevido dasfuncionalidades devido à ausência de correlação citada acima.3.12 CONTROLE DA EXECUÇÃO DA ORDEM DE SERVIÇOControlar a execução de uma ordem de serviço da Fábrica de Software equivaleao controle de projetos (FERNANDES, 2004). Devido à natureza do serviço, queenvolve entendimento dos requisitos de negócio ou técnicos, deve existirmecanismos que permitem controlar as mudanças de escopo, do cronograma ede custo e risco.Estas mudanças podem ou não ocasionar variações no tamanho funcional dasfuncionalidades descritas na Ordem de Serviço que nem sempre são refletidasna contagem de Pontos de Função do sistema e serviços já desenvolvidos.Caso tenha ocorrido variação, uma Ordem de Serviço complementar a originaldeve ser formalizada para registrar a mudança e a variação de tamanhofuncional.Normalmente a variação de tamanho funcional da Ordem de Serviço estárelacionada à mudança de escopo. O TSE entende alteração de escopo comoaquelas que decorrem da revisão das necessidades de negócio atendidas pelosistema, não originada pelo simples detalhamento dos requisitos identificados ouespecificados inicialmente.Na alteração de escopo, que resulta na alteração do tamanho funcional, afórmula de cálculo da quantidade de Pontos de Função devida à Fábrica deSoftware utiliza deflatores para as funcionalidades alteradas e excluídas.Após a análise a aprovação da mudança, mesmo para aquelas que não alteramo tamanho funcional, deve-se registrar sua justificativa, realizar umreplanejamento da execução da Ordem de Serviço e formalizá-la em umdocumento apropriado que esteja vinculado, por algum mecanismo, à Ordem deServiço original.É imprescindível estes registros, análises, aprovações e formalizações dasmudanças devido aos efeitos contratuais da Ordem de Serviço original,
  • 25. principalmente, os relacionados aos prazos de entrega. As mudanças podemsignificar ampliação dos prazos de execução dos serviços.Outra questão importante no controle da execução de Ordens de Serviços é ocontrole dos desvios de qualidade dos produtos e serviços entregue pela Fábricade Software, questão que será abordado em seguida.3.13 AVALIAÇÃO DA CONFORMIDADE DOS PRODUTOS E DOS SERVIÇOS ENTREGUES PELA FÁBRICA DE SOFTWAREDe acordo com a jurisprudência do TCU, é necessário definir como o órgãocontratante efetuará o recebimento, provisório e definitivo, do objeto, nos termosexigidos no Art. 40, inciso XVI da Lei nº 8.666/1993. (BRASIL, 2010d)Recebimento definitivo do objeto consiste na aceitação do produto licitado. Bense serviços aceitos poderão ter uso imediato ou ser incorporados ao patrimônioda Administração. Pode ser provisório ou definitivo (BRASIL, 2010d)Ainda 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 tempoverifique e comprove a adequação do objeto aos termos contratuais (BRASIL,1993). Estes termos são os critérios de avaliação de conformidade dos produtose dos serviços entregues pela fábrica de software.No caso do recebimento de serviços, os critérios de avaliação devem abrangermétricas, indicadores, inclusive de qualidade, segundo parâmetros e prazosaceitáveis (BRASIL, 2011i).Os critérios de avaliação dos produtos entregues pela Fábrica de Software sãogeralmente os critérios de avaliação de qualidade dos produtos do processo desoftware do órgão contratante.Quando são entregues produtos relacionados a requisitos de software ou osoftware em si, é importante que a área requisitante do software tambémparticipe dessa etapa de recebimento provisório, pois o fiscal do contrato e suaequipe técnica de apóio têm condições de avaliar os produtos entregues sob aótica da conformidade com o contrato e com os padrões da área de TI. A árearequisitante deve emitir parecer sobre a aderência dos artefatos aos requisitosda contratação voltados ao negócio, de modo que o órgão tenha maior garantiade que os produtos e serviços entregues produzirão os resultados pretendidos ede que a necessidade do órgão que gerou a contratação seja atendida. Portanto,é interessante que haja um duplo recebimento, pelo fiscal e pela árearequisitante (BRASIL, 2011i).Para tornar a avaliação mais objetiva e passível de ser realizada por váriosprofissionais de forma normalizada, uma boa prática é basear a avaliação emuma lista de verificação (checklist).Estando os produtos e serviços aderentes aos critérios de avaliação daqualidade e conformidade, o órgão público deve elaborar o Termo deRecebimento Definitivo, que será entregue à Contratada, autorizando esta aemitir a Nota Fiscal.Ressalta-se que como existe a possibilidade de entrega parcelada do objeto deuma Ordem de Serviço, existirá a necessidade de emitir os termos derecebimento, provisório e definitivo, separadamente para cada pacote deentrega identificado na Ordem de Serviço. Não é aceitável o recebimentoincompleto de um pacote de entrega parcial do objeto.
  • 26. 3.14 DESVIOS DE QUALIDADE E DE CONFORMIDADENos 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 emparte, o objeto do contrato em que se verificarem vícios, defeitos ou incorreçõesresultantes da execução ou de materiais empregados (BRASIL, 1993)Caso os produtos e serviços entregues pela Fábrica de Software não estejam deacordo com os Critérios de Aceitação estabelecidos no contrato e no processode software do órgão contratante, os desvios de qualidade e conformidadedeverão ser descritos e enviados ao Fiscal para que ele, por sua vez, tome asmedidas pertinentes (BRASIL, 2010e).O fiscal deve analisar os desvios e decidir sobre a aplicação de sanções ouencaminhamento de demandas de correção à Contratada. Caso opte pelaaplicação de sanções, o Fiscal deve elaborar um documento indicando ostermos contratuais aos quais o objeto da Ordem de Serviço não está aderente,com base nas avaliações de qualidade e conformidade. Este documento deve,então, ser encaminhado ao Gestor do Contrato, que, por sua vez, deveráanalisá-lo e encaminhar uma relação das possíveis sanções para a áreaadministrativa do órgão contratante.Assim como é imprescindível definir como o contratante efetuará o recebimento,provisório e definitivo, também é indispensável definir como as demandas decorreção dos produtos e serviços serão encaminhados à Contratada, bem como,os prazos e responsabilidades contratuais pertinentes.Os desvios e seus prazos de correção são bastante revelantes contratualmente,pois impactam no calculo dos indicadores de qualidade dos serviços, que sãoformalizados no termo de recebimento definitivo do objeto.No caso de ocorrência de divergências entre as partes contratuais (órgão públicoe a Fábrica de Software) quanto aos desvios de qualidade e conformidadesidentificados deve estabelecer as regras de resolução desta divergência nocontrato.Caso os desvios de qualidade identificados sejam enviados à Fábrica deSoftware para correção, caberá ao órgão contratante nova avaliação daqualidade e conformidade dos itens corrigidos. Ressalta-se que a eventualdevolução para correção de desvios não isenta a Contratada de eventuaispenalidades, a serem aplicadas quando do recebimento definitivo. (BRASIL,2010e)3.15 NÍVEIS DE SERVIÇODe acordo com a jurisprudência do TCU, é necessário definir níveis de serviçosem contratos de prestação de serviços (BRASIL, 2010d).Além dos critérios de aceitação dos produtos e serviços entregues, a Fábrica deSoftware deve atender os níveis de serviços. O descumprimento dos níveis deserviço sujeita a contratada a penalidades.O TSE utiliza 3 (três) indicadores: Atraso na Entrega (AE), Não-conformidadescom Requisitos (NC) e Erros de Operação (EO).Como já citado, estes indicadores são impactados pelos encaminhamentos àFábrica de Software das demandas de correção dos desvios de qualidade e deconformidade encontrados nos produtos e serviços entregues.Outro ponto importante para se destacar é que de acordo com o serviço eprodutos descritos em uma Ordem de Serviço, alguns indicadores não sãoviáveis de serem mensurados durante a execução daquele serviço.
  • 27. Assim, recomenda-se a utilização de indicadores simples, claros e objetivos combaixo custo de mensuração e que atenda os objetivos de controle dos serviços.Em virtude da exigência de clareza do objeto, não é possível negociar acordosde nível de serviço, na acepção mundialmente aceita, popularizada no ITIL(Information Technology Infrastructure Library), pois após a assinatura docontrato, o órgão público não dispõe de muita flexibilidade para alterar ascondições pactuadas. Assim, fica mais coerente com a legislação de licitações econtratos a utilização da expressão Nível Mínimo de Serviço Exigido, cujosparâmetros decorrerão dos requisitos obrigatórios do edital, ou da propostavencedora, quando esta superar os requisitos obrigatórios. O Nível Mínimo deServiç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 seratendidos pelos fornecedores, mas não deve ser objeto de negociação após aassinatura do contrato (BRASIL, 2011i).Recomenda-se que o Termo de Referência ou Projeto Básico descreva umconjunto de Indicadores de Nível Mínimo de Serviço e que cada Ordem deServiço informe quais indicadores serão aplicados, a critério do órgãocontratante, considerado os serviços e produtos demandados à Fábrica deSoftware.Os Indicadores de Nível Mínimo de Serviço devem ser detalhados no Termo deReferência ou Projeto com informações sobre: finalidade meta a cumprir,instrumento de medição, forma de acompanhamento, periodicidade, mecanismode cálculo, início de vigência, faixas de ajustes de pagamento e sanções.3.16 GARANTIA DOS SERVIÇOS E PRODUTOSA Fábrica de Software é obrigada a reparar, corrigir, remover, reconstruir ousubstituir, às suas expensas, no total ou em parte, o objeto do contrato em quese verificarem vícios, defeitos ou incorreções resultantes da execução ou demateriais empregados, nos termos no art. 69 da Lei nº 8.666/1993 (BRASIL,1993).No entanto, deve ser estabelecido no contrato prazos e responsabilidades dascorreções emergências dos softwares cujo erro em operação pode significargrande prejuízo ao órgão público.O prazo de garantia deve ser adequado para cobrir um período razoável quepermita a descoberta de um número considerável de defeitos ocultos nosprodutos ou serviços entregues pela Fábrica de Software. Recomenda-se que aFábrica de Software garanta os serviços prestados por pelo mesno 6 (seis)meses, contados da data de implantação da solução ou serviço no ambiente deprodução, mesmo após a finalização do contrato. E no caso da implantação dosoftware entregue e aceito não ser realizada no período de 45 (quarenta e cinco)dias corridos após a emissão do Termo de Recebimento Definitivo, recomenda-se o início do prazo de garantia a partir do esgotamento deste período.Como pode ocorrer a situação de que um componente de software e/ou artefatoreferente a um serviço da Fábrica de Software seja alterado pelo órgão públicoou por outro fornecedor por ele designado, para realização de atividades demanutenções, recomenda-se a definição de condições de manutenção daqualidade que não penalize a contratada na assunção de responsabilidadeslegais e contratuais que não lhe seja devido, mas a terceiros que alteraram osprodutos com imperícia ou negligência, provocando os defeitos.
  • 28. 3.17 TERMO DE REFERÊNCIA OU PROJETO BÁSICOOs Termos de Referência ou Projetos Básicos descrevem os elementosnecessários e suficientes, com nível de precisão adequado, para subsidiar oprocesso licitatório (BRASIL, 2010e). Ou seja, estes documentos devem contertodos os elementos capazes de definir o objeto, de forma clara, concisa eobjetiva, bem assim com nível de precisão adequado para caracterizar o bem ouo serviço (BRASIL,2010d).Em licitações realizadas na modalidade pregão, é obrigatória a elaboração determo de referência, que deve dispor sobre as condições gerais de execução docontrato. Termo de referência é documento prévio ao procedimento licitatório.Ele serve de base para elaboração do edital, a exemplo de projeto básico(BRASIL,2010d).O Termo de Referência ou Projeto Básico deve conter, no mínimo (BRASIL,2010e) (BRASIL, 2010d): 1. Definição do objeto; 2. Fundamentação da contratação; a. Relação Demanda X Necessidade; b. Motivação; c. Resultados a serem alcançados; d. Justificativa da solução escolhida. 3. Descrição da Solução de Tecnologia da Informação; 4. Requisitos da solução (Especificação Técnica); a. Considerações Gerais; b. Requisitos Internos; i. Requisitos Internos Funcionais; ii. Requisitos Internos Não-Funcionais (eg. Requisitos Temporais, Requisitos de Suporte, Requisitos de Qualidade, Requisitos de Padronização, Requisitos de Compatibilidade, Requisitos de Desempenho, Requisitos de Segurança da Informação, Requisitos de Segurança Institucional, Requisitos de Gestão Documental, Requisitos de Gestão do Conhecimento, Requisitos de Proteção do Direito Patrimonial e da Propriedade Intelectual, Requisitos de Gestão de Riscos Requisito de Gestão de Pessoa, Requisitos de Gestão Orçamentária, Requisitos de Gestão de Controlabilidade). c. Requisitos Externos (e.g. Políticas de Segurança da Informação, Padrões de Homologação e Certificação de Qualidade de Produtos de Informática, Políticas de Controle de Acesso, Metodologia de Gerenciamento de Projeto, Metodologia de Desenvolvimento de Sistemas, Normas Técnicas de Saúde e Segurança do Trabalho, Normas Gerais de Pessoal, Políticas Públicas de Proteção). 5. Modelo de prestação de serviços ou de fornecimento de bens; a. Justificativa do parcelamento do objeto; b. Metodologia de Trabalho; 6. Elementos para gestão do contrato; a. Papéis e Responsabilidades;
  • 29. b. Deveres e responsabilidades da contratante; c. Deveres e responsabilidades da contratada; d. Formas de acompanhamento do contrato; e. Metodologia de avaliação da qualidade; f. Níveis de Serviço; g. Estimativa de volume de bens / serviços; h. Prazos e Condições; i. Aceite, Alteração e Cancelamento; j. Condições para pagamento; k. Garantia; l. Propriedade, sigilo e restrições; m. Mecanismos Formais de Comunicação. 7. Estimativa de preços; 8. Adequação orçamentária; a. Fonte de Recursos. 9. Definições dos critérios de sanções; e 10. Critérios de seleção do fornecedor. a. Proposta Técnica; i. Organização. b. Qualificação técnica; i. Requisitos de Capacitação e Experiência. c. Critérios de seleção; i. Caracterização da Solução de Tecnologia da Informação. ii. Licitação.O Núcleo de Contratações de Tecnologia da Informação da SLTI/MPOG declaraque a Metodologia de Desenvolvimento de Sistemas do órgão públicocontratante deve compor o Termo de Referência ou Projeto Básico comorequisito externo, quando necessário.Eles argumentam que a metodologia de desenvolvimento estabelece osrequisitos que devem ser observados e monitorados durante os projetos,abrangendo métodos a serem utilizados, padrões de projeto e documentação(BRASIL, 2010e). O termo mais adequado que metodologia seria Processo deDesenvolvimento de Sistemas.No entanto, devido ao aspecto evolucionário dos Processos de Desenvolvimentode Sistemas, recomenda-se que o Termo de Referência ou Projeto Básicodescreva apenas requisitos que o órgão tem certeza acerca da suaimutabilidade e, de forma mais apropriada, referencie o documento que descrevedetalhadamente o processo de software, este suscetível a alterações durante avigência do contrato. Também deve-se definir a forma de comunicação dasalterações do processos e os prazos para início de vigências das mudanças.Excepcionalmente, se a alteração do processo de software ou de outro requisitoexpresso no Termo de Referência ou Projeto Básico alterar consideravelmentea relação econômica que as partes pactuaram inicialmente no contrato, com aimposição da execução de novas atividades ou elaboração de produtos queonere os custos operacionais da contratada, a pedido da contratada é possívelnegociar o restabelecimento do equilíbrio econômico-financeiro do contratado.Equilíbrio econômico-financeiro, assegurado pela Constituição Federal, consistena manutenção das condições de pagamento estabelecidas inicialmente no
  • 30. contrato, de maneira que se mantenha estável a relação entre as obrigações docontratado e a justa retribuição da Administração pelo fornecimento de bem,execução de obra ou prestação de serviço. Nas hipóteses expressamenteprevistas em lei, é possível à Administração, mediante acordo com o contratado,restabelecer o equilíbrio ou reequilíbrio econômico-financeiro do contrato(BRASIL, 2010d).Alguns fatos recorrentes entre os órgãos públicos e que geram diversosproblemas na execução dos contratos de Fábrica de Software são: • 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; • 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).Para exemplificar o risco da cópia do edital de uma instituição mais madura,considere que o modelo definido de acompanhamento do contrato pode indicar aelaboração e entrega de relatórios mensais sobre a sua execução e aplicaçãode multas previstas para algumas desconformidades por parte da contratada.Assim, se forem identificados problemas que poderiam ter sido evitadosmediante a análise desses relatórios sem que tenha havido ação do responsávela respeito (e.g. não aplicou advertência ou multa prevista no contrato), o fiscaldo contrato e os demais envolvidos na gestão contratual terão que explicarporque não sugeriram a aplicação de sanção à contratada (BRASIL, 2011i).O caso de alteração dos requisitos expresso no Termo de Referência ou ProjetoBásico, bem como o caso de cópia de edital de outra instituição, resultafrequentemente na necessidade de ajustes no contrato durante sua execução,devido a estas e outras falhas no planejamento da contratação. No entanto, casoalguma alteração proposta pelo órgão gere ônus à contratada, ela dificilmenteaceitará o ajuste (e.g. aditivo contratual) e não haverá nada que o órgão possafazer, especialmente se as alterações propostas gerarem novos procedimentosou produtos de maior qualidade, bem como demandarem mão de obra maisqualificada. Destaca-se que, na prática, as possibilidades de alteração docontrato são bastante limitadas. (BRASIL, 2011i).Por este motivo, novamente, recomenda-se que os Processos deDesenvolvimento de Sistemas não sejam totalmente incluídos no Termo deReferência ou no Projeto Básico, para evitar que as alterações dos processossejam por meio de aditivos contratuais. Apenas recomenda-se que estesdocumentos referenciam ao documento detalhado do processo de software eexija que a Contratada deva seguir os padrões e processos de TI do órgãocontratado, listados no Termo de Referência ou Projeto Básico, que podem seralterados a critério do contratante para atender necessidades organizacionais.4 CONCLUSÃOEste artigo apresentou as principais recomendações relacionadas aos principaisproblemas e dificuldades observados em contratos de fábrica de software naAdministração Pública Federal e no TSE. O principal problema observado é afalta de maturidade dos órgãos públicos no processo de planejamento dacontratação de Fábrica de Software que impacta no modelo de gestão docontrato. A qualidade da gestão do contrato depende, em grande medida, dostrabalhos desenvolvidos na fase de planejamento da contratação, pois é no
  • 31. planejamento que as regras da gestão contratual são estabelecidas. A execuçãoinfrutífera e onerosa do contrato para o órgão público frequentemente nãoproduz os resultados pretendidos que atendam à necessidade que deu origem àcontratação.Portanto, recomenda-se a execução cuidadosa e criteriosa da fase deplanejamento da contratação de Fábrica de Software. No entanto, a capacitaçãode servidores da área de TI em planejamento de contratação de serviços de TI eem gestão dos contratos decorrentes é fundamental para que existam servidoresminimamente capacitados para executar esses processos de planejamento egestão. Como esses tópicos são complexos e dinâmicos, a capacitação deve sercontínua. Adicionalmente, devem constar dos programas dos concursos públicosque selecionem servidores para atuar na área de gestão de TI. Os servidores daárea de TI devem também ser capacitados nos processos de ciclo de vida dossoftwares, nos modelos de maturidade e capacidade de processos de software enos modelos de processos de softwares.5 BIBLIOGRAFIAOffice of Government Commerce. ITIL Version 3: Service Strategy Servicedelivery. United Kingdom, 2007.BRASIL. Tribunal de Contas da União. Acórdão 381/2011-TCU-Plenário.Relatório de auditoria. avaliação de controles gerais de tecnologia dainformação. Constatação de irregularidades, precariedades e oportunidades demelhoria. Determinações, recomendações e alertas. 2011a._____. _____. Acórdão 111/2011-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2011b._____. _____. Acórdão 380/2011-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2011c._____. _____. Acórdão 465/2011-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2011d._____. _____. Acórdão 592/2011-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2011e._____. _____. Acórdão 757/2011-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2011f._____. _____. Acórdão 758/2011-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2011g._____. _____. Acórdão 866/2011-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação de
  • 32. irregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2011h._____. _____. Guia de Contratação de Soluções de Tecnologia daInformação - Riscos e controles para o planejamento da contratação.Brasília: TCU. 2011i._____. _____. Acórdão 2746/2010-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2010a._____. _____. Acórdão 2938/2010-TCU-Plenário. Relatório de auditoria.avaliação de controles gerais de tecnologia da informação. Constatação deirregularidades, precariedades e oportunidades de melhoria. Determinações,recomendações e alertas. 2010b._____. _____. Acórdão 2.308/2010-TCU-Plenário. Relatório de levantamento.Avaliação da governança de tecnologia da informação na administração públicafederal. Constatação de precariedades e oportunidades de melhoria.Determinações, recomendações e comunicações. 2010c._____. _____. Licitações e Contratos - Orientações e Jurisprudência doTCU. 4. ed.Brasília: TCU. 2010d._____. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logísticae Tecnologia da Informação. Instrução normativa nº 4, de 12 de novembro de2010. Dispõe sobre o processo de contratação de Soluções de Tecnologia daInformação pelos órgãos integrantes do Sistema de Administração dos Recursosde Informação e Informática (Sisp) do Poder Executivo Federal. 2010d.Disponível em:<http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-04-de-12-denovembro- de-2010>. Acesso em: 22 set. 2011._____. _____. Guia Prático para Contratação de Soluções de Tecnologia daInformação. Versão 1.1, Brasília: SLTI, 2010e. Disponível em: <http://www.governoeletronico.gov.br/biblioteca/arquivos/guia-pratico-para-contratacao-de-solucoes-de-ti-mcti>. Acesso em: 22 set. 2011._____. Decreto-Lei 200, de 25 de fevereiro de 1967. Dispõe sobre aorganização da Administração Federal, estabelece diretrizes para a ReformaAdministrativa e dá outras providências. 1967. Disponível em:<http://www.planalto.gov.br/ccivil/decreto-lei/Del0200.htm>. Acessado em 22 set.2011._____. Lei n° 8.666, de 21 de junho de 1993 . Regulamenta o art. 37, incisoXXI, da Constituição Federal, institui normas para licitações e contratos daAdministração Pública e dá outras providências. 1993. Disponível em:<http://www.planalto.gov.br/ccivil_03/Leis/L8666cons.htm>. Acesso em: 22 set.2011.CRUZ, Cláudio Silva da; ANDRADE, Edméia Leonor Pereira de; FIGUEIREDO,Rejane Maria da Costa. Ministério da Ciência, Tecnologia e Inovação. Processode contratação de serviços de tecnologia da informação para organizaçõespúblicas. Brasília: MCTI, 2011. Disponível em: <http://www.mct.gov.br/upd_blob/0216/216919.pdf>. Acesso em: 22 set. 2011.Eduardo Margara da Silva, Fernando JoséFERNANDES, Aguinaldo Aragon, TEIXEIRA, Descartes de Souza. Fábrica deSoftware – Implantação e gestão de operações, São Paulo: ATLAS, 2004
  • 33. INFORMATION TECHNOLOGY GOVERNANCE INSTITUTE - ITGI. COBIT -Control Objectives for Information and related Technology. 4.1. ed. (emportuguês). Rolling Meadows: ITGI, 2007. Disponível em:<http://www.isaca.org/Knowledge- Center/cobit/Documents/cobit41-portuguese.pdf>. Acesso em: 22 set. 2011._____. Governance of Outsourcing. Rolling Meadows: ITGI, 2005. Disponívelem:<http://www.isaca.org/Content/ContentGroups/Research1/Deliverables/Outsourcing.pdf>. Acesso em: 22 set. 2011.INTERNATIONAL FUNCTION POINT USERS GROUP. Counting PracticesManual: Release 4.2, Ohio: IFPUG, 2004.LAURINDO, Barbin; PESSOA, Marcelo Schneck de Paula, Fábricas de software:o sucesso depende mais do projeto, dos fornecedores ou dos gestores? Estudode caso numa operadora de Telecomunicações. In: 3º CONTECSI –International Conference on Information Systems and TechnologyManagement - Congresso Internacional de Tecnologia e Sistemas deInformação, 2006, Laboratório de Tecnologia e Sistemas de Informação daFaculdade de Economia, Administração e Contabilidade da Universidade de SãoPaulo (TECSI/EAC/FEA/USP), São Paulo, 2006. Disponível em:<http://www.lideravantti.com.br/artigos/sucesso-em-fabricas-de-software.pdf>.Acesso em: 22 dez. 2011.PRESSMAN, R. Software Engineering - A Pratitioners Approach, 7th ed,Boston, Massachusetts: McGraw-Hill, 2010.SOFTWARE ENGINEERING INSTITUTE - SEI. Capability Maturity ModelIntegration CMMI for Development (CMMI-DEV), version 1.3, CMU/SEI-2010-TR-033. Pittsburgh, PA: Software Engineering Institute, Carnegie MellonUniversity, 2010. Disponível em: <http://www.sei.cmu.edu/reports/10tr033.pdf>.Acesso em: 22 set. 2011.SOMMERVILE, I. Software Engineering. 8d, Pearson, 2007.