{"id":18494,"date":"2019-11-11T15:04:18","date_gmt":"2019-11-11T17:04:18","guid":{"rendered":"http:\/\/www.conass.org.br\/guiainformacao\/?page_id=18494"},"modified":"2019-11-11T16:58:56","modified_gmt":"2019-11-11T18:58:56","slug":"capitulo-2-orientacoes-para-a-elaboracao-e-especificacao-das-regras-de-negocio-para-a-contratacao-de-servicos-ou-aquisicao-de-solucoes-de-ti-aplicativos-ou-sistemas-informatizados-para-a-g","status":"publish","type":"page","link":"https:\/\/www.conass.org.br\/guiainformacao\/capitulo-2-orientacoes-para-a-elaboracao-e-especificacao-das-regras-de-negocio-para-a-contratacao-de-servicos-ou-aquisicao-de-solucoes-de-ti-aplicativos-ou-sistemas-informatizados-para-a-g\/","title":{"rendered":"Cap\u00edtulo 2 \u2013 Orienta\u00e7\u00f5es para a elabora\u00e7\u00e3o e especifica\u00e7\u00e3o das regras de neg\u00f3cio para a contrata\u00e7\u00e3o de servi\u00e7os ou aquisi\u00e7\u00e3o de solu\u00e7\u00f5es de TI (aplicativos ou sistemas informatizados) para a gest\u00e3o estadual do SUS"},"content":{"rendered":"<p><a id=\"topo\" title=\"Topo da Pagina\" href=\"#\"><img decoding=\"async\" class=\"alignnone size-full wp-image-6746\" src=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2015\/02\/topo1.png\" sizes=\"(max-width: 78px) 100vw, 78px\" srcset=\"https:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2015\/02\/topo1.png 78w, https:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2015\/02\/topo1-50x50.png 50w\" alt=\"topo\" width=\"78\" height=\"77\" \/><\/a><\/p>\n<h3>Introdu\u00e7\u00e3o<\/h3>\n<p>Neste segundo cap\u00edtulo, o principal objetivo \u00e9 demostrar aos gestores que a contrata\u00e7\u00e3o de software se divide em dois grandes grupos: os aplicativos de prateleira e o desenvolvimento de aplicativos espec\u00edficos, personalizados e com foco em atendimento de demandas n\u00e3o encontradas.<\/p>\n<h3>Vamos Falar de <em>Software<\/em><\/h3>\n<p>Existem diversas defini\u00e7\u00f5es t\u00e9cnicas para o que \u00e9 software, variando desde a mais simples, que separa a parte f\u00edsica da parte l\u00f3gica dos componentes de um ambiente computacional em que a parte l\u00f3gica ganha esse nome, at\u00e9 uma das mais difundidas, que classifica como uma sequ\u00eancia de instru\u00e7\u00f5es a serem seguidas, manipuladas ou ainda executadas por um computador.<\/p>\n<p>Por sua exist\u00eancia imaterial, ela \u00e9 de dif\u00edcil entendimento ou enquadramento em alguns momentos. A grande maioria das empresas entende que um software \u00e9 um bem de capital, logo, faz parte do processo de valora\u00e7\u00e3o de uma empresa, consta como um ativo e tem deprecia\u00e7\u00e3o. Outra leitura \u2013 e essa muito aceita, especialmente nas unidades governamentais \u2013 entende que um software \u00e9 um bem de consumo, ou seja, \u00e9 um servi\u00e7o a ser prestado. Essa posi\u00e7\u00e3o adotada por diversos \u00f3rg\u00e3os de governo que divergem da opini\u00e3o geral do mercado se baseia em alguns aspectos importantes de comportamento. Os mais relevantes para a quest\u00e3o p\u00fablica s\u00e3o: a incapacidade de colocar um n\u00famero de patrim\u00f4nio, como um bem, conforme prev\u00ea a Lei 4.320\/1964, que diz que todos os bens adquiridos pelos \u00f3rg\u00e3os da administra\u00e7\u00e3o p\u00fablica devem ter seu referido controle patrimonial; como tamb\u00e9m a necessidade de licenciamento anual, que obriga um novo desembolso para um bem j\u00e1 adquirido para continuar se utilizando dele com plena capacidade e o mantendo atualizado.<\/p>\n<p>O mundo do software pode ser facilmente dividido em dois grandes grupos que t\u00eam caracter\u00edsticas similares de funcionamento: destina\u00e7\u00f5es diferenciadas de objeto e fluxos de aquisi\u00e7\u00e3o extremamente distintos. Apesar de n\u00e3o prevista em lei, a jurisprud\u00eancia administrativa federal e estadual vem cada vez mais ratificando o entendimento que, para fins tribut\u00e1rios e de aquisi\u00e7\u00e3o, existem dois tipos b\u00e1sicos de programa de computador, o \u201csoftware Personalizado\u201d e o \u201csoftware de prateleira\u201d, que receber\u00e3o tratamento tribut\u00e1rio distinto (servi\u00e7o ou mercadoria) em raz\u00e3o da forma de sua produ\u00e7\u00e3o e comercializa\u00e7\u00e3o.<\/p>\n<p>O reconhecimento pela jurisprud\u00eancia de dois tipos b\u00e1sicos de programa de computador (personalizado e prateleira) ficou consolidado em 1998, ap\u00f3s o julgamento pelo STF do Recurso Extraordin\u00e1rio n\u00ba 176626 (rel. Min. Sep\u00falveda Pertence).<\/p>\n<p>O \u201csoftware personalizado\u201d \u00e9 comumente definido pela jurisprud\u00eancia como \u201cprograma de computador produzido sob encomenda para atender a necessidade espec\u00edfica de determinado usu\u00e1rio\u201d, enquanto o \u201csoftware de prateleira\u201d \u00e9 definido como \u201cprograma de computador produzido em larga escala de maneira uniforme e colocado no mercado para aquisi\u00e7\u00e3o por qualquer interessado sob a forma de c\u00f3pias m\u00faltiplas\u201d.<\/p>\n<p>A Lei do Software (Lei n\u00ba 9.609\/98) conceitua o programa de computador da seguinte maneira:<\/p>\n<blockquote><p>Art. 1\u00ba \u2013 Programa de computador \u00e9 a express\u00e3o de um conjunto organizado de instru\u00e7\u00f5es em linguagem natural ou codificada, contida em suporte f\u00edsico de qualquer natureza, de emprego necess\u00e1rio em m\u00e1quinas autom\u00e1ticas de tratamento da informa\u00e7\u00e3o, dispositivos, instrumentos ou equipamentos perif\u00e9ricos, baseados em t\u00e9cnica digital ou an\u00e1loga, para faz\u00ea-los funcionar de modo e para fins determinados.<\/p><\/blockquote>\n<p>Como se v\u00ea, previu-se que todo programa de computador (instru\u00e7\u00f5es) estaria gravado em um suporte f\u00edsico de qualquer natureza (o que atualmente nem sempre acontece), ainda assim, esta conceitua\u00e7\u00e3o d\u00e1 base ao entendimento de que o programa de computador, quando gravado em um suporte f\u00edsico, \u00e9 um bem imaterial (incorp\u00f3reo) quanto ao programa (dados ou instru\u00e7\u00f5es) e bem material (corp\u00f3reo) quanto ao suporte f\u00edsico como o <em>compact disc<\/em> ou mem\u00f3ria flash.<\/p>\n<p>A legisla\u00e7\u00e3o equipara o programa de computador \u00e0s obras intelectuais (fruto da intelectualidade humana), determinando que \u00e9 necess\u00e1rio possuir autoriza\u00e7\u00e3o do autor como os contratos de licen\u00e7a para sua utiliza\u00e7\u00e3o.<\/p>\n<h3>Software de Prateleira<\/h3>\n<p>O software de prateleira \u00e9 aquele que j\u00e1 est\u00e1 pronto para uso e que, na pr\u00e1tica, teria um custo de desenvolvimento muito maior do que utilizar algo que est\u00e1 comercialmente dispon\u00edvel. Volta-se a recordar que a legisla\u00e7\u00e3o brasileira para software equipara programas para computador com obras intelectuais, logo protegidas pela lei de propriedade intelectual, Lei 9279\/96. S\u00e3o exemplos de software de prateleira:<\/p>\n<ul>\n<li>Sistema Operacional;<\/li>\n<li>Antiv\u00edrus;<\/li>\n<li>Pacotes de automa\u00e7\u00e3o de escrit\u00f3rio com editores de texto e planilhas de c\u00e1lculos;<\/li>\n<li>Bancos de dados;<\/li>\n<li>Gest\u00e3o de Estoque;<\/li>\n<li>Gest\u00e3o Empresarial;<\/li>\n<li>Pacotes de virtualiza\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>Todos esses softwares de prateleira t\u00eam atrelado a si um contrato de licen\u00e7a de uso que d\u00e1 todo suporte legal, define os direitos e os deveres do contratante deste software. Por vezes, esse documento altamente importante \u00e9 resumido com um simples clique depois da express\u00e3o \u201cEu Aceito\u201d.<\/p>\n<p>Esse contrato de licen\u00e7a de software pode ser uma licen\u00e7a comercial ou uma licen\u00e7a livre. Neste momento, vamos tratar aqui do aspecto comercial e como ele impacta no processo de sele\u00e7\u00e3o e contrata\u00e7\u00e3o, enquanto o aspecto da licen\u00e7a livre ser\u00e1 tratado no t\u00f3pico de Software Livre.<\/p>\n<h3>Licen\u00e7a Comercial<\/h3>\n<p>O termo licen\u00e7a comercial \u00e9 normalmente associado e designado a contratos de licenciamento de uso de software para o funcionamento empresarial. Os softwares chamados comerciais s\u00e3o aqueles pelos quais o usu\u00e1rio paga uma taxa de licenciamento para poder utiliz\u00e1-los.<\/p>\n<p>\u00c9 importante observar que, de acordo com o modelo de licenciamento de software comercial, o que o usu\u00e1rio adquire quando paga pelo software \u00e9 o direito de utiliz\u00e1-lo segundo as regras definidas por seu contrato de licenciamento de uso. Uma analogia pode ser feita com livros: quando se compra um livro, est\u00e1 se adquirindo a m\u00eddia impressa, mas o direito autoral do conte\u00fado \u00e9 do autor ou da editora.<\/p>\n<p>As duas restri\u00e7\u00f5es mais comuns nas licen\u00e7as comerciais s\u00e3o:<\/p>\n<ul>\n<li>O direito de redistribui\u00e7\u00e3o, por exemplo, realizar uma c\u00f3pia dele e repass\u00e1-la para outro usu\u00e1rio. A c\u00f3pia de softwares em desacordo com sua licen\u00e7a comercial \u00e9 considerada uma c\u00f3pia ilegal e esta pr\u00e1tica \u00e9 conhecida pelo termo pirataria.<\/li>\n<li>O direito de alterar o funcionamento do software, adaptando-o para um fim espec\u00edfico. Como o software comercial raramente \u00e9 distribu\u00eddo com seu c\u00f3digo-fonte, para alter\u00e1-lo, seria necess\u00e1rio utilizar a pr\u00e1tica da engenharia reversa, o que costuma ser terminantemente proibido por esse tipo de licen\u00e7a.<\/li>\n<\/ul>\n<p>A Licen\u00e7a comercial define tamb\u00e9m, em muitos casos, os servi\u00e7os que a empresa que vende o software disponibiliza para os usu\u00e1rios que adquirem seu direito de uso, tais como suporte, corre\u00e7\u00e3o de erros de funcionamento, atualiza\u00e7\u00e3o peri\u00f3dica e acesso a documenta\u00e7\u00e3o de uso e outros materiais \u2013 normalmente via Internet.<\/p>\n<h3>Especifica\u00e7\u00e3o<\/h3>\n<p>A etapa mais importante de qualquer processo de aquisi\u00e7\u00e3o de produto ou servi\u00e7o \u00e9 a especifica\u00e7\u00e3o t\u00e9cnica que dever\u00e1 estar contida no processo licitat\u00f3rio. Ela \u00e9 um marco da sua necessidade evidente e \u00e9 o nivelador entre as ofertas dos fornecedores. Quando falamos de software de prateleira, normalmente pensamos em existir mais de um fornecedor para aquele mesmo objetivo; e mesmo quando n\u00e3o h\u00e1 mais de um fornecedor, haver\u00e1 sempre mais de uma empresa habilitada a poder vender praticando ofertas diferenciadas.<\/p>\n<p>S\u00e3o pontos comuns da especifica\u00e7\u00e3o de software de prateleira:<\/p>\n<h4>Suporte T\u00e9cnico<\/h4>\n<p>Atendimento realizado pelo fabricante para tratar de eventuais problemas no funcionamento do software em decorr\u00eancia de falhas de engenharia do produto ou para dirimir d\u00favidas sobre o uso do produto. Difere de outros servi\u00e7os que podem ser prestados por revendedores, ou pelo pr\u00f3prio fabricante, que t\u00eam car\u00e1ter de consultoria ou de atendimento t\u00e9cnico para intervir no ambiente computacional para resolver situa\u00e7\u00f5es decorrentes de mau uso do software.<\/p>\n<p>Para suporte t\u00e9cnico, \u00e9 fundamental que seja claro no documento de especifica\u00e7\u00e3o que tipo de suporte t\u00e9cnico \u00e9 esperado e, da mesma forma que falaremos em hardware, \u00e9 primordial que se especifique o tempo, seja para o primeiro atendimento, seja para a solu\u00e7\u00e3o do problema. Recomendamos sempre pensar em tempo de solu\u00e7\u00e3o, pois a\u00ed se tem, de fato, o objeto referente ao chamado t\u00e9cnico resolvido. Outro aspecto essencial no item de suporte t\u00e9cnico \u00e9 identificar de que forma ele ocorrer\u00e1, pois n\u00e3o ser\u00e1 incomum a necessidade de abrir um chamado no fabricante usando a l\u00edngua inglesa; se isso for um empecilho, \u00e9 mandat\u00f3rio que fique claro no item de suporte t\u00e9cnico a l\u00edngua que ser\u00e1 utilizada para contatar a central de atendimento.<\/p>\n<p>\u00c9 mandat\u00f3rio tamb\u00e9m especificar por quanto tempo se deseja que o suporte seja v\u00e1lido.<\/p>\n<h4>Manuten\u00e7\u00e3o do Software<\/h4>\n<p>Disponibiliza\u00e7\u00e3o, por parte do fabricante, de componente de software (bug fix) com vistas a corrigir um comportamento disfuncional do software, derivado de engenharia do produto, e que \u00e9 aplicado sobre uma determinada vers\u00e3o.<\/p>\n<p>Na quest\u00e3o de manuten\u00e7\u00e3o de software, \u00e9 mandat\u00f3rio que a continuidade do produto seja clara, pois um investimento maior que o da aquisi\u00e7\u00e3o \u00e9 o da substitui\u00e7\u00e3o de uma plataforma que ser\u00e1 descontinuada. Todo fabricante de software disponibiliza, mesmo que para uso interno, um \u201c<em>roadmap\u201d<\/em> do produto, com o planejamento de aprimoramento da plataforma, mudan\u00e7as significativas de arquitetura e novas capacidades. \u00c9 nesse documento que, por exemplo, consegue-se mapear a elimina\u00e7\u00e3o de alguma plataforma computacional que pode ser relevante para a utiliza\u00e7\u00e3o do produto, como, por exemplo, a extin\u00e7\u00e3o de uma plataforma em 32 bits.<\/p>\n<p>\u00c9 mandat\u00f3rio tamb\u00e9m especificar por quanto tempo se deseja que a manuten\u00e7\u00e3o de software seja v\u00e1lida.<\/p>\n<h4>Instala\u00e7\u00e3o<\/h4>\n<p>Disponibiliza\u00e7\u00e3o, por parte do fabricante ou do seu representante autorizado, de implanta\u00e7\u00e3o completa do software, ou parcial, de forma que entreguem uma nova vers\u00e3o est\u00e1vel do produto. Podem, tamb\u00e9m, incluir as aplica\u00e7\u00f5es das corre\u00e7\u00f5es de comportamentos disfuncionais que n\u00e3o tenham sido corrigidos por manuten\u00e7\u00f5es anteriores do software, por crit\u00e9rio do contratante.<\/p>\n<p>Neste ponto, \u00e9 fundamental que seja pensada pelo contratante a possibilidade de transfer\u00eancia de tecnologia. Essa etapa diminui consideravelmente a depend\u00eancia do fornecedor e empodera a equipe de tecnologia a utilizar mais plenamente o software.<\/p>\n<p>Caso deseje a instala\u00e7\u00e3o do software, \u00e9 providencial que haja o planejamento para uma etapa de inspe\u00e7\u00e3o nas depend\u00eancias onde ser\u00e1 feita a instala\u00e7\u00e3o. Nesse momento, deve ser apresentado o hardware no qual ser\u00e1 feita a instala\u00e7\u00e3o. Somente empresas que passem e apresentem o documento de comparecimento na inspe\u00e7\u00e3o ou visita t\u00e9cnica estar\u00e3o habilitadas a continuar o processo licitat\u00f3rio.<\/p>\n<p>Ap\u00f3s os itens que s\u00e3o gerais a todos os softwares de prateleira, como suporte, manuten\u00e7\u00e3o e instala\u00e7\u00e3o, segue uma sequ\u00eancia de especifica\u00e7\u00f5es que deixam claro o objeto da aquisi\u00e7\u00e3o. N\u00e3o \u00e9 incomum haver diversos fornecedores para um bem comum como software de prateleira, por isso, a caracteriza\u00e7\u00e3o espec\u00edfica do seu software \u00e9 t\u00e3o importante, mas tamb\u00e9m \u00e9 importante manter sempre o princ\u00edpio da imparcialidade na escolha. Por mais que haja um ajuste mental de que a marca \u201cA\u201d \u00e9 melhor que a marca \u201cB\u201d, n\u00e3o havendo motivo t\u00e9cnicos claros para estabelecer a diferen\u00e7a entre elas, ambas devem ser consideradas para o processo licitat\u00f3rio.<\/p>\n<p>Essa talvez seja a parte mais delicada do trabalho de elabora\u00e7\u00e3o, visto que ela consome tempo, muito tempo, mas, se bem feita, pode resolver in\u00fameros problemas para a administra\u00e7\u00e3o. Ouso dizer que o segredo est\u00e1 no equil\u00edbrio das demandas em que todas as necessidades t\u00e9cnicas est\u00e3o colocadas; e a quantidade de fornecedores coberta pela proposta maximiza a concorr\u00eancia, gerando assim economia ao er\u00e1rio p\u00fablico.<\/p>\n<p>Principais categorias de software de prateleira e suas principais caracter\u00edsticas:<\/p>\n<h3>Antiv\u00edrus<\/h3>\n<p>Essa \u00e9 uma das categorias que mais tem fornecedores e na qual \u00e9 esperada uma concorr\u00eancia acirrada. Durante a especifica\u00e7\u00e3o, vale a pena destacar alguns pontos:<\/p>\n<p><strong>Finalidade de Uso<\/strong> \u2013 Esta\u00e7\u00e3o de trabalho, servidor ou sistema m\u00f3vel como tablets e celulares. Cada dispositivo desse pode apresentar uma m\u00e9trica diferente no licenciamento e nos valores (especialmente quando se fala de servidores).<\/p>\n<p><strong>Sistema Operacional<\/strong> \u2013 H\u00e1 a necessidade de prover cobertura para todos os sistemas operacionais existentes na unidade, inclusive os mais antigos; e esse \u00e9 um ponto problem\u00e1tico, pois sabemos que temos esta\u00e7\u00f5es de trabalho mais antigas, com pouca mem\u00f3ria, em que um antiv\u00edrus mais pesado poderia inviabilizar sua atividade.<\/p>\n<p><strong>Fluxo de instala\u00e7\u00e3o<\/strong> \u2013 Diversos antiv\u00edrus hoje possuem um mecanismo de instala\u00e7\u00e3o automatizado e silencioso. Na automatiza\u00e7\u00e3o, \u00e9 capaz de instalar em m\u00e1quinas de um departamento inteiro de uma \u00fanica vez; e em outras situa\u00e7\u00f5es, o modo silencioso faz com que o usu\u00e1rio nem perceba que est\u00e1 sendo instalado na sua esta\u00e7\u00e3o de trabalho.<\/p>\n<p><strong>Administra\u00e7\u00e3o do ambiente<\/strong> \u2013 Temos que lembrar sempre que administrar um parque de equipamentos \u00e9 muito mais complexo que administrar nossa pr\u00f3pria esta\u00e7\u00e3o de trabalho, logo, \u00e9 fundamental um console de administra\u00e7\u00e3o que permita que sejam vistos todos os recursos ativos (equipamentos) e sua situa\u00e7\u00e3o quanto \u00e0 atualiza\u00e7\u00e3o. Outro ponto importante na administra\u00e7\u00e3o \u00e9 impedir que o usu\u00e1rio final consiga remover o antiv\u00edrus da esta\u00e7\u00e3o de trabalho; deve haver pol\u00edtica onde somente o administrador qualificado do ambiente possa fazer esse tipo de atividade.<\/p>\n<p><strong>Atualiza\u00e7\u00e3o Centralizada<\/strong> \u2013 Imagina aquele cen\u00e1rio em que o seu antiv\u00edrus avisa a todas as esta\u00e7\u00f5es de trabalho para sa\u00edrem da internet, buscando uma nova vers\u00e3o da defini\u00e7\u00e3o de v\u00edrus em um mesmo momento do dia? O resultado seria catastr\u00f3fico para sua conex\u00e3o de sa\u00edda com a internet, e \u00e9 por essa raz\u00e3o que um processo de atualiza\u00e7\u00e3o centralizada \u00e9 t\u00e3o importante. Nesse modelo, apenas uma m\u00e1quina central traz toda a atualiza\u00e7\u00e3o do antiv\u00edrus para sua rede local e, posteriormente, \u00e9 distribu\u00edda via rede local para as esta\u00e7\u00f5es de trabalho.<\/p>\n<p><strong>Antiv\u00edrus Gratuito<\/strong> \u2013 Muito cuidado com esse item, pois existem diversos antiv\u00edrus de uso gratuito no mercado, mas a grande maioria deles deixa expl\u00edcito que a vers\u00e3o gratuita \u00e9 para uso em computadores pessoais, e n\u00e3o corporativos. O uso desses produtos de forma inadequada pode acarretar multas severas.<\/p>\n<h3>Banco de Dados<\/h3>\n<p>Esse tipo de software, quando comercial, quase sempre \u00e9 dominado por duas empresas, o que gera um cen\u00e1rio em que ou se escolhe nominalmente qual a solu\u00e7\u00e3o a ser adotada, ou se faz um grande teste ou PoC (Proof of Concept) e validar inicialmente qual sua melhor ader\u00eancia a determinado fornecedor. Essa escolha \u00e9 determinante, pois esse tipo de software tem sua substitui\u00e7\u00e3o t\u00e3o complexa que, por vezes, v\u00ea-se acontecendo renova\u00e7\u00f5es desse tipo de software, insatisfeito com o servi\u00e7o prestado ou produto apresentado e sem capacidade efetiva de substitui\u00e7\u00e3o.<\/p>\n<p>O banco de dados raramente \u00e9 o item final de uma compra. Normalmente, ele \u00e9 decorrente de um produto comprado que precisa ser ampliado, e, nesse caso, h\u00e1 jurisprud\u00eancia que suporte a especifica\u00e7\u00e3o nominal do produto, pois, independentemente de qual seja, existem diversas empresas fornecedoras para esses produtos e h\u00e1 previsibilidade de concorr\u00eancia.<\/p>\n<p>S\u00e3o pontos de destaque no momento da sele\u00e7\u00e3o:<\/p>\n<p><strong>Edi\u00e7\u00e3o do Banco de Dados<\/strong> \u2013 \u00c9 bem comum que esse tipo de produto, dentro de uma mesma vers\u00e3o, ganhe edi\u00e7\u00f5es com capacidades diferenciadas, normalmente conhecidas como \u201cStandard\u201d e \u201cEnterprise\u201d, podendo haver v\u00e1rias outras. Tem-se por tr\u00e1s disso uma s\u00e9rie de diferen\u00e7as de recursos espec\u00edficos, logo, se a licita\u00e7\u00e3o for feita por produto nomeado, h\u00e1 a necessidade de especificar de forma totalmente inequ\u00edvoca a edi\u00e7\u00e3o ou de apontar detalhadamente quais os recursos s\u00e3o importantes, sempre considerando que a segunda hip\u00f3tese abre um risco grande uma vez que os fornecedores podem fazer movimenta\u00e7\u00f5es de recursos para melhor atender a um determinado processo de compra.<\/p>\n<p><strong>Modelo de Licenciamento<\/strong> \u2013 O modelo de licenciamento de banco de dados normalmente est\u00e1 amarrado \u00e0 capacidade computacional a que se deseja atender. Nesse caso, a m\u00e9trica mais estabelecida \u00e9 a quantidade de n\u00facleos dos processadores que ser\u00e1 atendida. H\u00e1 sempre uma quest\u00e3o importante que \u00e9 a exist\u00eancia de n\u00facleos f\u00edsicos e n\u00facleos l\u00f3gicos. \u00c9 a\u00ed que tudo pode se complicar. Para n\u00e3o correr risco, verifique a m\u00e9trica que o fornecedor utiliza e dimensione em fun\u00e7\u00e3o do equipamento que ser\u00e1 alvo de utiliza\u00e7\u00e3o. Verifique se h\u00e1 diferen\u00e7a do modelo de licenciamento caso esse banco de dados for ser executado em plataformas virtuais, pois h\u00e1 a possiblidade de uma contagem diferenciada ou produto diferenciado para plataformas virtualizadas.<\/p>\n<p><strong>Suporte a Virtualiza\u00e7\u00e3o<\/strong> \u2013 Virtualiza\u00e7\u00e3o e banco de dados s\u00e3o normalmente alvos de utiliza\u00e7\u00e3o antag\u00f4nicas, contudo, atualmente, \u00e9, sim, uma estrat\u00e9gia manter ambientes virtuais e com bancos de dados em execu\u00e7\u00e3o sobre eles. O destaque aqui fica por conta do suporte do fabricante a ambientes virtualizados, j\u00e1 que existem fornecedores que exigem que a virtualiza\u00e7\u00e3o ocorra em plataforma espec\u00edfica do fabricante.<\/p>\n<h3>O Ac\u00f3rd\u00e3o do TCU 2.569\/2018<\/h3>\n<p>O Tribunal de Contas da Uni\u00e3o (TCU) fez uma auditoria sobre as pr\u00e1ticas comerciais dos grandes fornecedores de software ao governo federal e concluiu que os \u00f3rg\u00e3os p\u00fablicos contam com muito menos informa\u00e7\u00f5es do que deveriam, o que traz s\u00e9rios riscos de danos ao Er\u00e1rio. Em especial, o TCU indica que h\u00e1 pouca prepara\u00e7\u00e3o para compras no modelo de computa\u00e7\u00e3o em nuvem, ainda que o mercado aponte ser a tend\u00eancia natural de contrata\u00e7\u00e3o.<\/p>\n<p>\u201cA principal conclus\u00e3o a que chegou este trabalho \u00e9 que existe uma situa\u00e7\u00e3o de hipossufici\u00eancia da Administra\u00e7\u00e3o P\u00fablica Federal em rela\u00e7\u00e3o aos grandes fabricantes de software. H\u00e1 pouca ou nenhuma margem de negocia\u00e7\u00e3o da APF ante a esses fornecedores, o que imp\u00f5e a adapta\u00e7\u00e3o da contrata\u00e7\u00e3o p\u00fablica aos modelos de neg\u00f3cio privados, que s\u00e3o d\u00edspares entre as solu\u00e7\u00f5es similares, bem como modificam-se em ritmo acelerado\u201d, indica o relat\u00f3rio que sustenta o Ac\u00f3rd\u00e3o 2.569\/18.<\/p>\n<p>Diante das complexidades identificadas, o TCU faz uma s\u00e9rie de recomenda\u00e7\u00f5es aos \u00f3rg\u00e3os p\u00fablicos, a come\u00e7ar pela defesa de que prevale\u00e7am as compras conjuntas, nas quais s\u00e3o agregadas as demandas de diversos \u00f3rg\u00e3os. Contudo, uma das medidas que atingem em cheio o modelo de comercializa\u00e7\u00e3o atual \u00e9 a determina\u00e7\u00e3o da Corte de Contas para que seja proibido o pagamento \u00e0 vista de licen\u00e7as de software.<\/p>\n<p>Assim, entre as medidas est\u00e1 determinar aos \u00f3rg\u00e3os p\u00fablicos que \u201cadquiram o quantitativo de licen\u00e7as estritamente necess\u00e1rio, vedando-se o pagamento antecipado por licen\u00e7as de software e vinculando o pagamento dos servi\u00e7os agregados \u00e0s licen\u00e7as efetivamente utilizadas, principalmente em projetos considerados de alto risco ou de longo prazo, nos quais o quantitativo deve ser atrelado \u00e0 evolu\u00e7\u00e3o do empreendimento, e devidamente documentado nos estudos t\u00e9cnicos preliminares\u201d.<\/p>\n<p>O relator, Aroldo Cedraz, diz que esse pagamento \u00e0 vista \u00e9 a metodologia corrente e defendida por ser a forma internacionalmente praticada pelo mercado. \u201cN\u00e3o socorre esse racioc\u00ednio o fato de que os grandes fabricantes de software adotam globalmente a prerrogativa de pagamento antecipado, uma vez que, sendo o contrato executado em solo brasileiro, deve-se respeitar a legisla\u00e7\u00e3o p\u00e1tria\u201d, sustentou no voto, acompanhado pelos demais ministros.<\/p>\n<p>A s\u00e9rie de determina\u00e7\u00f5es e recomenda\u00e7\u00f5es comp\u00f5em o Ac\u00f3rd\u00e3o 2569\/18 e s\u00e3o fruto da auditoria que analisou compras de software e servi\u00e7os realizadas entre janeiro de 2012 e novembro de 2016, per\u00edodo em que foram identificadas aquisi\u00e7\u00f5es de pelo menos R$ 2,8 bilh\u00f5es junto a meia d\u00fazia de desenvolvedores, sendo um ter\u00e7o delas somente com a Microsoft \u2013 e 85% concentradas na pr\u00f3pria Microsoft, IBM e Oracle.<\/p>\n<p>Acesse a <a href=\"https:\/\/contas.tcu.gov.br\/pesquisaJurisprudencia\/#\/detalhamento\/11\/%252a\/NUMACORDAO%253A2569%2520ANOACORDAO%253A2018\/DTRELEVANCIA%2520desc%252C%2520NUMACORDAOINT%2520desc\/false\/1\/false\">integra do ac\u00f3rd\u00e3o do TCU<\/a> pode ser encontrada, em que se pode extrair o texto completo da mat\u00e9ria. Cabe destacar que como se trata de um ac\u00f3rd\u00e3o extremamente novo, de novembro de 2018, ainda n\u00e3o puderam ser dimensionadas todas suas poss\u00edveis repercuss\u00f5es.<\/p>\n<h2>Software Personalizado<\/h2>\n<p>O desenvolvimento de software personalizado para os governos \u00e9, sem sombra de d\u00favida, um dos grandes desafios que qualquer gestor de TICS da \u00e1rea p\u00fablica encontra pela frente. Quando falamos de software personalizado, estamos falando daquele produto que \u00e9 feito sob medida para atender \u00e0s demandas espec\u00edficas de uma secretaria ou unidade de neg\u00f3cios, sendo que esse desenvolvimento n\u00e3o \u00e9 incomum, devido a s\u00e9rias particularidades que s\u00e3o encontradas apenas nos servi\u00e7os p\u00fablicos e pelo fato de que poucas empresas de desenvolvimento de software se veem atra\u00eddas a desenvolver solu\u00e7\u00f5es de prateleira para atender a essa demanda.<\/p>\n<p>Tenha em mente que esse tipo de desenvolvimento sempre ser\u00e1 o resultado dos esfor\u00e7os do contratado para prestar o servi\u00e7o de desenvolvimento com a \u00e1rea final que tem a necessidade de automatizar algum processo. \u00c9 o time de tecnologia local que tem a tarefa de especificar e gerir as entregas. Por vezes, na equipe interna, n\u00e3o h\u00e1 disponibilidade de agente de especifica\u00e7\u00e3o, e essa atividade acaba sendo remetida a um prestador de servi\u00e7o externo. Essa situa\u00e7\u00e3o grave poder\u00e1 ter um crescente no risco da qualidade do produto entregue.<\/p>\n<p>A mec\u00e2nica do desenvolvimento de software personalizado por si s\u00f3 j\u00e1 requer um grau de conhecimento alto nas disciplinas da ci\u00eancia da computa\u00e7\u00e3o que abordam o tema. Quando falamos do desenvolvimento para o servi\u00e7o p\u00fablico, toda uma nova linguagem de artefatos vem \u00e0 tona, quando tornamos isso ainda mais espec\u00edfico colocando itens de sa\u00fade no meio, a chance de encontrar empresas que entendam do que est\u00e1 sendo dito \u00e9 baix\u00edssima.<\/p>\n<p>Nessa perspectiva em que \u00e9 muito dif\u00edcil encontrar empresas que conhe\u00e7am da sua demanda para que possam lhe apoiar no processo de desenvolvimento, a forma\u00e7\u00e3o do profissional que exerce o papel de \u201canalista de sistemas de sa\u00fade\u201d \u00e9 das compet\u00eancias mais importantes. Esse profissional ser\u00e1 o respons\u00e1vel em apoiar as \u00e1reas da sa\u00fade que conhecem sua demanda e traduzir para uma linguagem mais neutra e amig\u00e1vel esperada pelos desenvolvedores.<\/p>\n<p>O modelo de desenvolvimento atual quase sempre remete a passos como:<\/p>\n<ol>\n<li>Levantar a demanda com a \u00e1rea usu\u00e1ria do sistema a ser desenvolvido;<\/li>\n<li>Escrever essa rotina de forma neutra e amig\u00e1vel;<\/li>\n<li>Validar se essa escrita corresponde ao desejo da \u00e1rea fim;<\/li>\n<li>Levar a demanda \u00e0 equipe de desenvolvimento;<\/li>\n<li>Receber da equipe de desenvolvimento o fragmento que foi desenvolvido;<\/li>\n<li>Validar se o que foi especificado foi entregue;<\/li>\n<li>Apresentar para a \u00e1rea fim o fragmento validando se o que foi solicitado ficou adequado \u00e0 especifica\u00e7\u00e3o.<\/li>\n<\/ol>\n<p>Apesar de parecer um fluxo relativamente simples, diversos riscos devem ser percebidos aqui. Destaque para:<\/p>\n<ul>\n<li>Nem toda necessidade foi mapeada pela \u00e1rea usu\u00e1ria na hora do levantamento;<\/li>\n<li>A especifica\u00e7\u00e3o deixou brechas para entendimentos que possam resultar em um desenvolvimento n\u00e3o adequado;<\/li>\n<li>As partes do desenvolvimento n\u00e3o se encaixam gerando um sistema, virando assim seguimentos sem conex\u00e3o.<\/li>\n<\/ul>\n<p>Al\u00e9m das etapas anteriores, h\u00e1 tamb\u00e9m a necessidade de atentar a detalhes t\u00e9cnicos de legisla\u00e7\u00e3o, por exemplo, aqui vale citar a portaria espec\u00edfica de padr\u00f5es de interoperabilidade de sa\u00fade (<a href=\"http:\/\/bvsms.saude.gov.br\/bvs\/saudelegis\/gm\/2011\/prt2073_31_08_2011.html\">Portaria n\u00ba 2.073 de 2011<\/a>) que estabelece diversos padr\u00f5es para troca de informa\u00e7\u00f5es em sa\u00fade; e al\u00e9m dessa, existem diversas adapta\u00e7\u00f5es que devem ser respeitadas como padr\u00f5es de acessibilidade em uma p\u00e1gina web, como a eMag, padr\u00f5es de interoperabilidade de Governo Eletr\u00f4nico ePING, layout web, identidade visual, entre outros, que devem ser detalhadas antes do desenvolvimento para que n\u00e3o haja retrabalho para se adaptar \u00e0s normativas existentes.<\/p>\n<h3>Desenvolvimento Fechado<\/h3>\n<p>Esse tipo de processo licitat\u00f3rio \u00e9 de grande risco, uma vez que ele compreende apresentar de uma vez s\u00f3 todos os requerimentos necess\u00e1rios para o desenvolvimento, dessa forma, a empresa contratada dever\u00e1 apresentar uma proposta financeira para o desenvolvimento dessas fichas de requerimento, gerando, assim, o produto, que \u00e9 o sistema de informa\u00e7\u00e3o.<\/p>\n<p>Essa situa\u00e7\u00e3o pode ter riscos mitigados, fazendo com que as entregas sejam parciais e que a cada momento seja avaliada a qualidade do que est\u00e1 sendo entregue, tentando assim diminuir o impacto no final do processo.<\/p>\n<p>Itens que n\u00e3o podem faltar em um processo de escopo fechado de desenvolvimento:<\/p>\n<ul>\n<li>Defini\u00e7\u00e3o clara da tecnologia a ser utilizada;<\/li>\n<li>Defini\u00e7\u00e3o clara dos componentes tecnol\u00f3gicos, como banco de dados, servidor de aplica\u00e7\u00e3o, plataforma de integra\u00e7\u00e3o que podem ser utilizadas;<\/li>\n<li>Frequ\u00eancia das apresenta\u00e7\u00f5es parciais do produto;<\/li>\n<li>Apresenta\u00e7\u00e3o formal do canal de acompanhamento do projeto;<\/li>\n<li>Apresenta\u00e7\u00e3o seguindo metodologia de desenvolvimento de sistema \u2013 sugest\u00e3o para prefer\u00eancia por metodologias \u00e1geis;<\/li>\n<li>Previsibilidade de per\u00edodo de garantia do sistema se assegurando que ao menos um ciclo completo de utiliza\u00e7\u00e3o se complete;<\/li>\n<li>Previsibilidade e defini\u00e7\u00e3o de valor para manuten\u00e7\u00e3o em fun\u00e7\u00e3o de mudan\u00e7as na especifica\u00e7\u00e3o inicial.<\/li>\n<\/ul>\n<h3>F\u00e1brica de Software<\/h3>\n<p>A contrata\u00e7\u00e3o de uma f\u00e1brica de software \u00e9 uma estrat\u00e9gia muito utilizada quando se deseja desenvolver um software personalizado. Ela consiste na terceiriza\u00e7\u00e3o do desenvolvimento, como no caso do desenvolvimento fechado, mas difere no quesito do escopo, j\u00e1 que este foi definido previamente.<\/p>\n<p>A utiliza\u00e7\u00e3o de f\u00e1brica de software requer uma organiza\u00e7\u00e3o importante uma vez que os componentes que v\u00e3o fazer o desenvolvimento do software n\u00e3o t\u00eam conhecimento do todo, apenas da parte que est\u00e1 sendo enviada para cada um. Dessa forma, a qualidade da documenta\u00e7\u00e3o \u00e9 fundamental para que o produto de retorno seja adequado.<\/p>\n<p>O uso de f\u00e1brica de software \u00e9 tido como um modelo bem aceito dentro dos governos, tanto que j\u00e1 houve v\u00e1rias normativas e portarias para regular seu uso, por\u00e9m, sempre h\u00e1 um ponto de impasse \u2013 qual a m\u00e9trica a ser utilizada para a contrata\u00e7\u00e3o?<\/p>\n<p>No governo federal, a Secretaria de Tecnologia da Informa\u00e7\u00e3o, \u00f3rg\u00e3o do Minist\u00e9rio do Planejamento, lan\u00e7ou a <a href=\"http:\/\/www.in.gov.br\/materia\/-\/asset_publisher\/Kujrw0TZC2Mb\/content\/id\/20823254\/do1-2017-03-08-portaria-n-4-de-6-de-marco-de-2017-20823187\">Portaria n\u00ba 4, de 2017<\/a>, que estabelece o seguinte:<\/p>\n<blockquote><p>CAP\u00cdTULO I<\/p>\n<p>DAS DISPOSI\u00c7\u00d5ES GERAIS<\/p>\n<p>Art. 1\u00ba Nas contrata\u00e7\u00f5es de servi\u00e7os de desenvolvimento, manuten\u00e7\u00e3o e sustenta\u00e7\u00e3o de software devem ser definidas m\u00e9tricas objetivas que permitam a gest\u00e3o contratual, a mensura\u00e7\u00e3o e a devida remunera\u00e7\u00e3o dos servi\u00e7os e produtos efetivamente entregues pela empresa contratada no contexto do processo de desenvolvimento de software adotado pelo \u00f3rg\u00e3o ou entidade.<\/p>\n<p>Art. 2\u00ba Quando o \u00f3rg\u00e3o ou entidade optar por adotar m\u00e9trica espec\u00edfica para mensura\u00e7\u00e3o de software em suas contrata\u00e7\u00f5es, devem ser referenciados os normativos e manuais t\u00e9cnicos que definem as regras de uso e o c\u00e1lculo da m\u00e9trica de software escolhida, bem como o escopo da sua aplica\u00e7\u00e3o.<\/p><\/blockquote>\n<p>Ainda na mesma portaria \u00e9 dito:<\/p>\n<blockquote><p>CAP\u00cdTULO II<\/p>\n<p>DA UTILIZA\u00c7\u00c3O DE M\u00c9TRICAS EM SERVI\u00c7OS DE DESENVOLVIMENTO DE SOFTWARE<\/p>\n<p>Art. 5\u00ba Entende-se como servi\u00e7o de desenvolvimento de software o conjunto de atividades a serem executadas com a finalidade de atender \u00e0s necessidades do \u00f3rg\u00e3o ou entidade por meio da implementa\u00e7\u00e3o de um novo software ou de uma nova funcionalidade, em conformidade com a metodologia de desenvolvimento por ele estabelecida e aplicados os procedimentos necess\u00e1rios \u00e0 garantia da qualidade para desenvolvimento.<\/p><\/blockquote>\n<p>Essa portaria revoga determina\u00e7\u00e3o anterior em que a \u00fanica m\u00e9trica aceit\u00e1vel, pelo governo federal, \u00e9 a m\u00e9trica de ponto de fun\u00e7\u00e3o (PF). De fato, a m\u00e9trica PF tem sido muito utilizada como unidade monet\u00e1ria (R$\/PF) nos contratos de desenvolvimento e manuten\u00e7\u00e3o de sistemas pelas organiza\u00e7\u00f5es governamentais brasileiras. Esse tipo de contrato permite o melhor balanceamento de riscos entre contratante e contratada, sendo recomendado pela Instru\u00e7\u00e3o Normativa \u2013 IN04 e pelos \u00d3rg\u00e3os de Controle do Governo Brasileiro.<\/p>\n<h3>Ponto de Fun\u00e7\u00e3o<\/h3>\n<p>A m\u00e9trica Pontos de Fun\u00e7\u00e3o &#8211; PF foi criada por Allan Albrecht, em 1979, visando minimizar as dificuldades associadas ao uso da m\u00e9trica Linhas de C\u00f3digo (LOC) como unidade de medida de tamanho de software, bem como suportar a previs\u00e3o do esfor\u00e7o de desenvolvimento do projeto de software. Em 1986, uma Pesquisa do Quality Assurance Institute mostrou que PF \u00e9 a melhor m\u00e9trica para o estabelecimento de medi\u00e7\u00f5es de qualidade e produtividade de projetos de software. Em 1993, PF se tornou a m\u00e9trica mais utilizada e estudada na Engenharia de Software. Atualmente, a m\u00e9trica de PF continua sendo a mais utilizada na ind\u00fastria de software como m\u00e9trica padr\u00e3o na defini\u00e7\u00e3o de indicadores, como insumo para deriva\u00e7\u00e3o de estimativas de prazo, custo e esfor\u00e7o e no estabelecimento de contratos de software. Esta se\u00e7\u00e3o tem como prop\u00f3sito apresentar uma vis\u00e3o geral da contagem de PF, baseando-se nas regras de contagem do Counting Practices Manual (CPM) 4.3 (INTERNATIONAL FUNCTION POINT USERS GROUP, 2009).<\/p>\n<p>Os principais objetivos da an\u00e1lise de PF s\u00e3o os seguintes:<\/p>\n<ul>\n<li>Medir a funcionalidade requisitada e recebida pelo usu\u00e1rio;<\/li>\n<li>Medir projetos de desenvolvimento e de manuten\u00e7\u00e3o evolutiva de software independentemente da tecnologia utilizada na implementa\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>A contagem de PF n\u00e3o ajustados consiste no mapeamento dos requisitos funcionais do projeto de software nos cinco tipos funcionais da An\u00e1lise de Pontos de Fun\u00e7\u00e3o: Arquivo L\u00f3gico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE), Sa\u00edda Externa (SE), conforme ilustrado na Figura 1.<\/p>\n<p>&nbsp;<\/p>\n<p><a href=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Fig1-2.png\"><img fetchpriority=\"high\" decoding=\"async\" class=\"alignnone size-medium\" src=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Fig1-2.png\" width=\"885\" height=\"437\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n<p>O ALI &#8211; Arquivo L\u00f3gico Interno \u00e9 um grupo l\u00f3gico de dados, mantido dentro da fronteira da aplica\u00e7\u00e3o, por meio de um ou mais processos elementares. O AIE &#8211; Arquivo de Interface Externa \u00e9 um grupo l\u00f3gico de dados, referenciado por um ou mais processos elementares da aplica\u00e7\u00e3o; contudo, eles s\u00e3o mantidos dentro da fronteira de outra aplica\u00e7\u00e3o. Uma EE &#8211; Entrada Externa \u00e9 um processo elementar que processa dados ou informa\u00e7\u00e3o de controle que vem de fora da fronteira da aplica\u00e7\u00e3o. O seu objetivo principal \u00e9 manter um ou mais ALI ou alterar o comportamento da aplica\u00e7\u00e3o. Uma Sa\u00edda Externa \u00e9 um processo elementar que envia dados ou informa\u00e7\u00e3o de controle para fora da fronteira da aplica\u00e7\u00e3o. O seu objetivo principal \u00e9 apresentar informa\u00e7\u00f5es para o usu\u00e1rio por meio de um processamento l\u00f3gico que deve conter: c\u00e1lculos ou criar dados derivados ou manter ALI ou alterar o comportamento da aplica\u00e7\u00e3o. Uma Consulta Externa \u00e9 um processo elementar que envia dados ou informa\u00e7\u00e3o de controle para fora da fronteira da aplica\u00e7\u00e3o. O seu objetivo principal \u00e9 apresentar informa\u00e7\u00e3o para o usu\u00e1rio por meio apenas de uma recupera\u00e7\u00e3o de dados ou informa\u00e7\u00e3o de controle de um ALI ou AIE.<\/p>\n<p>Cada fun\u00e7\u00e3o identificada possui uma complexidade associada: Simples, M\u00e9dia ou Complexa e uma contribui\u00e7\u00e3o para a contagem de Pontos de Fun\u00e7\u00e3o N\u00e3o Ajustados, baseada na sua complexidade (Tabela 1). A determina\u00e7\u00e3o da complexidade e da contribui\u00e7\u00e3o funcional n\u00e3o \u00e9 subjetiva, sendo baseada nas regras de contagem do CPM (INTERNATIONAL FUNCTION POINT USERS GROUP, 2009).<\/p>\n<p><strong>Tabela 1: Contribui\u00e7\u00e3o Funcional dos Tipos de Fun\u00e7\u00e3o [IFPUG, 2009]<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p><a href=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Tabela1.png\"><img decoding=\"async\" class=\"alignnone size-medium\" src=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Tabela1.png\" width=\"885\" height=\"393\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n<p>A utiliza\u00e7\u00e3o do procedimento de contagem de Pontos de Fun\u00e7\u00e3o &#8211; PF, descrito no CPM [IFPUG, 2009], implica na exist\u00eancia do projeto l\u00f3gico da aplica\u00e7\u00e3o. Nas fases iniciais do processo de desenvolvimento de software, os PF n\u00e3o podem ser medidos, e, sim, estimados. Sugere-se a utiliza\u00e7\u00e3o do m\u00e9todo Contagem Estimativa de Pontos de Fun\u00e7\u00e3o (CEPF) nas estimativas de tamanho dos projetos de software para o estabelecimento de contratos ou elabora\u00e7\u00e3o de Editais.<\/p>\n<p>O Tribunal de Contas do Estado de S\u00e3o Paulo emitiu o seguinte parecer para uso geral:<\/p>\n<blockquote><p>Metodologias para contrata\u00e7\u00e3o de desenvolvimento, manuten\u00e7\u00e3o, corre\u00e7\u00e3o e melhoria de software na Administra\u00e7\u00e3o P\u00fablica<\/p>\n<p>&#8230;<\/p>\n<p>\u00c9 importante observar que o objetivo da medi\u00e7\u00e3o em Pontos de Fun\u00e7\u00e3o n\u00e3o \u00e9 o de medir diretamente esfor\u00e7o, produtividade ou custo. Mas em conjunto com outras vari\u00e1veis &#8211; como a tecnologia utilizada, capacita\u00e7\u00e3o e conhecimento da equipe, metodologia de desenvolvimento, etc. &#8211; a quantidade de Pontos de Fun\u00e7\u00e3o medidos poder\u00e1 ser usada para derivar produtividade, estimar esfor\u00e7o e custo do projeto de software. Al\u00e9m disso, o acompanhamento do desenvolvimento de software poder\u00e1 ser realizado utilizando-se os Pontos de Fun\u00e7\u00e3o \u2013 por exemplo, verificando se as funcionalidades (mais precisamente, tamanho funcional em pontos de fun\u00e7\u00e3o) est\u00e3o sendo entregues no prazo.<\/p>\n<p>A ado\u00e7\u00e3o da An\u00e1lise de Pontos por Fun\u00e7\u00e3o &#8211; APF, al\u00e9m de substituir as estimativas feitas atualmente, tende tamb\u00e9m a substituir os modelos de contrata\u00e7\u00e3o por homem\/hora ou por postos de trabalho. Por isso, inicialmente \u00e9 esperada a resist\u00eancia de v\u00e1rias partes acostumadas a estes formatos de contrata\u00e7\u00e3o.<\/p>\n<p>Tudo que inova incomoda a quem est\u00e1 na zona de conforto. A inform\u00e1tica \u00e9 assim, sempre ligada na \u201cvelocidade dos bits\u201d!<\/p>\n<p>Vale ressaltar que a ado\u00e7\u00e3o da APF \u00e9 um caminho a ser consolidado na Administra\u00e7\u00e3o P\u00fablica paulista, pois se trata de uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria (manuten\u00e7\u00e3o evolutiva) de software.<\/p>\n<p>A APF permite a medi\u00e7\u00e3o objetiva de servi\u00e7os de desenvolvimento de solu\u00e7\u00f5es de software, por isso a ado\u00e7\u00e3o dessa medida \u00e9 uma boa pr\u00e1tica na contrata\u00e7\u00e3o de servi\u00e7os e est\u00e1 aderente ao Princ\u00edpio da Efici\u00eancia.<\/p><\/blockquote>\n<h3>Homem-Hora<\/h3>\n<p>Este modelo \u00e9 aquele que se caracteriza pela aloca\u00e7\u00e3o de profissionais terceirizados no desenvolvimento de aplica\u00e7\u00f5es. O conceito Homem-Hora \u00a0-HH pode ser aplicado a outras modalidades que n\u00e3o somente o desenvolvimento de software, contudo, ele vem sendo criticado pelos gestores que o contratam por ter uma remunera\u00e7\u00e3o desvinculada dos resultados, gerando assim um paradoxo que pode ser dif\u00edcil de administrar, que \u00e9 o que diz que quanto mais improdutivo eu sou mais eu recebo por isso.<\/p>\n<p>Outro aspecto que tamb\u00e9m se destaca na contrata\u00e7\u00e3o HH \u00e9 que o escopo n\u00e3o precisa estar totalmente definido para trabalhar. Se por um lado isso pode ser visto como ponto a favor pela flexibilidade aceita a mudan\u00e7as do escopo do projeto; por outro lado, tamb\u00e9m sinaliza que h\u00e1 evidentes problemas no processo de levantamento de dados.<\/p>\n<p>A modalidade de contrata\u00e7\u00e3o de HH foi duramente criticada no governo federal, sendo que a IN04 chegou a proibir esse tipo de contrata\u00e7\u00e3o para o desenvolvimento de software. Hoje esse modelo de contrata\u00e7\u00e3o \u00e9 permitido, mas ainda h\u00e1 muitas ressalvas na sua utiliza\u00e7\u00e3o que, por v\u00e1rias vezes, pode ser vista como uma forma de terceiriza\u00e7\u00e3o do pr\u00f3prio departamento de TICS dos \u00f3rg\u00e3os.<\/p>\n<p>S\u00e3o os principais itens a se destacar no processo de contrata\u00e7\u00e3o no modelo HH:<\/p>\n<ul>\n<li>Determinar qual o perfil profissional esperado;<\/li>\n<li>Determinar qual a tecnologia a ser utilizada;<\/li>\n<li>Determinar a quantidade total de horas a serem utilizadas e qual a distribui\u00e7\u00e3o;<\/li>\n<li>Determinar os pesos de utiliza\u00e7\u00e3o das horas t\u00e9cnicas.<\/li>\n<\/ul>\n<p>Uma das possibilidades em uma contrata\u00e7\u00e3o seguindo o modelo HH \u00e9 que seja fixado um valor hora base; e partindo dele, crie-se multiplicadores como pesos identificando a modalidade e complexidade da atividade a ser executada, dessa forma, ao inv\u00e9s de ter um valor para cada perfil de profissional, ter\u00e1 um grande montante de horas que podem ser distribu\u00eddas da melhor forma para o projeto.<\/p>\n<p>A contrata\u00e7\u00e3o de projetos de softwares personalizados por HH, quando pass\u00edvel de an\u00e1lise pelo TCU, pode esbarrar em uma determina\u00e7\u00e3o estipulada pela S\u00famula Vinculante N 269:<\/p>\n<blockquote><p>S\u00daMULA N\u00ba 269<\/p>\n<p>Nas contrata\u00e7\u00f5es para a presta\u00e7\u00e3o de servi\u00e7os de tecnologia da informa\u00e7\u00e3o, a remunera\u00e7\u00e3o deve estar vinculada a resultados ou ao atendimento de n\u00edveis de servi\u00e7o, admitindo-se o pagamento por hora trabalhada ou por posto de servi\u00e7o somente quando as caracter\u00edsticas do objeto n\u00e3o o permitirem, hip\u00f3tese em que a excepcionalidade deve estar pr\u00e9via e adequadamente justificada nos respectivos processos administrativos.<\/p><\/blockquote>\n<h3>Requisito de Software<\/h3>\n<p>Independentemente do modelo de contrata\u00e7\u00e3o, seja por hora-homem, seja por ponto de fun\u00e7\u00e3o, a elabora\u00e7\u00e3o do documento de requisito de software \u00e9 fundamental para que o projeto de desenvolvimento seja bem-sucedido.<\/p>\n<p>A elabora\u00e7\u00e3o dos requisitos de software sempre deve vir precedido do conjunto de software que fa\u00e7a a manuten\u00e7\u00e3o b\u00e1sica desse programa de computador \u2013 entenda por manuten\u00e7\u00e3o b\u00e1sica a capacidade de criar usu\u00e1rios, capacidade de criar grupos com regras de acesso e estipular as regras de acesso a determinados grupos de usu\u00e1rios. Quanto mais rica for essa etapa, mais segura e detalhada ser\u00e1 sua capacidade de gerir os usu\u00e1rios. Um fato sempre importante de avaliar nas regras gerais \u00e9 a capacidade de visualizar e editar cada informa\u00e7\u00e3o. Quanto mais fragmentada for a necessidade de visualiza\u00e7\u00e3o\/edi\u00e7\u00e3o de cada informa\u00e7\u00e3o no sistema de informa\u00e7\u00e3o, mais importante \u00e9 a capacidade que dever\u00e1 existir nesse conjunto b\u00e1sico. Um exemplo hipot\u00e9tico, imagine um sistema de informa\u00e7\u00e3o no qual haver\u00e1 uma tela de cadastramento de pessoas. Nessa tela, constam algumas informa\u00e7\u00f5es importantes e sens\u00edveis como, por exemplo, o medicamento que ela est\u00e1 tomando. Imagine agora que essa informa\u00e7\u00e3o referente a medicamento dever\u00e1 estar dispon\u00edvel apenas \u00e0 equipe cl\u00ednica, \u00e9 fundamental que a parte b\u00e1sica do sistema seja capaz de identificar essa situa\u00e7\u00e3o e conseguir dar acesso \u00e0 parte dos medicamentos apenas aos profissionais que fa\u00e7am parte do grupo que deve ter acesso.<\/p>\n<p>A estrutura b\u00e1sica de um processo de requisito de software faz parte da Engenharia de Software e pode ser dividida seguindo o seguinte esquema:<\/p>\n<p>&nbsp;<\/p>\n<p><a href=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/fig2.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium\" src=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/fig2.png\" width=\"595\" height=\"270\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n<p>Para come\u00e7ar a falar sobre requisitos funcionais e n\u00e3o funcionais, precisamos entender o que s\u00e3o requisitos. Eles s\u00e3o solicita\u00e7\u00f5es, desejos, necessidades. Um requisito \u00e9 a propriedade que um software exibe para solucionar problemas reais, \u00e9 a conjuntura indispens\u00e1vel para satisfazer um objeto.<\/p>\n<p>Quando se trata de um software sob demanda, por exemplo, um requisito \u00e9 uma maneira pela qual o sistema oferecido deve fazer, ou um condicionamento no desenvolvimento do sistema. Lembrando que, em ambas as a\u00e7\u00f5es, embora o programador ou o arquiteto de software tenha suas opini\u00f5es, \u00e9 importante chegar em um acordo para resolver o problema do cliente. Esse sempre ser\u00e1 o foco.<\/p>\n<p>\u00c9 muito importante frisar que manter uma concord\u00e2ncia com os clientes e com aqueles envoltos \u00e9 um dos principais objetivos dos requisitos.<\/p>\n<p>Um dos principais respons\u00e1veis pelo sucesso dos softwares, os requisitos, s\u00e3o a base para estimativas, modelagem, projeto, execu\u00e7\u00e3o, testes e at\u00e9 mesmo para a sua manuten\u00e7\u00e3o.<\/p>\n<p>Assim, os requisitos est\u00e3o presentes ao longo de todo o ciclo de vida de um software.<\/p>\n<p>Ao come\u00e7ar um projeto, os requisitos j\u00e1 devem ser levantados, entendidos e documentados. Assim como realizar atividades de controle de qualidade para verificar, validar e garantir a qualidade deles.<\/p>\n<p>Gerenciar a evolu\u00e7\u00e3o dos requisitos \u00e9 importante, estando cientes de que os neg\u00f3cios com sua din\u00e2mica n\u00e3o garantem estabilidade e podem vir a sofrer altera\u00e7\u00f5es. Desse modo, \u00e9 necess\u00e1rio manter a rastreabilidade entre os requisitos e as outras pe\u00e7as do projeto.<\/p>\n<h3>Requisito Funcional<\/h3>\n<p>Esclarecido o que s\u00e3o requisitos, \u00e9 hora de desmembr\u00e1-los explicando cada um. Come\u00e7aremos, portanto, pelos requisitos funcionais.<\/p>\n<p>Dentro da engenharia de softwares, podemos destacar o requisito funcional, em que h\u00e1 a materializa\u00e7\u00e3o de uma necessidade ou solicita\u00e7\u00e3o realizada por um software. Por\u00e9m, v\u00e1rios requisitos funcionais podem ser realizados dentro de uma mesma funcionalidade.<\/p>\n<p>S\u00e3o variadas as fun\u00e7\u00f5es e os servi\u00e7os que um sistema pode fornecer ao seu cliente. Descrevemos abaixo algumas das in\u00fameras fun\u00e7\u00f5es que os softwares podem executar:<\/p>\n<ul>\n<li>Incluir\/Excluir\/Alterar nome em uma tela de manuten\u00e7\u00e3o de funcion\u00e1rio.<\/li>\n<li>Gera\u00e7\u00e3o de relat\u00f3rio de determinado per\u00edodo de dispensa\u00e7\u00e3o de medicamento.<\/li>\n<li>Efetuar pagamentos de compra atrav\u00e9s de cr\u00e9dito ou d\u00e9bito.<\/li>\n<li>Consulta e altera\u00e7\u00f5es de dados pessoais de usu\u00e1rios.<\/li>\n<li>Emiss\u00e3o de relat\u00f3rios de clientes ou vendas.<\/li>\n<li>Consulta de saldo ou estoque.<\/li>\n<\/ul>\n<p>Os requisitos funcionais s\u00e3o de extrema import\u00e2ncia no desenvolvimento de aplicativos, pois, sem eles, n\u00e3o h\u00e1 funcionalidades nos sistemas.<\/p>\n<p>Seus modelos devem ser constru\u00eddos em um n\u00edvel de entendimento claro e objetivo, al\u00e9m de um c\u00f3digo-fonte totalmente aplic\u00e1vel. Conclus\u00e3o: para obter requisitos funcionais de qualidade, a f\u00e1brica de software deve estar atenta \u00e0 s\u00edntese e \u00e0 sem\u00e2ntica deles.<\/p>\n<h3>Requisito n\u00e3o Funcional<\/h3>\n<p>Uma vez que os requisitos funcionais definem o que o sistema far\u00e1, a Engenharia de Software afirma que os requisitos n\u00e3o funcionais definem como o sistema far\u00e1, embora n\u00e3o seja t\u00e3o clara assim essa defini\u00e7\u00e3o.<\/p>\n<p>Os Requisitos n\u00e3o Funcionais n\u00e3o est\u00e3o relacionados diretamente com as funcionalidades de um sistema. Tamb\u00e9m chamados de atributos de qualidade, ainda assim s\u00e3o de grande import\u00e2ncia no desenvolvimento do sistema.<\/p>\n<p>Tratados geralmente como premissas e restri\u00e7\u00f5es t\u00e9cnicas de um projeto, os requisitos n\u00e3o funcionais s\u00e3o praticamente todas as necessidades que n\u00e3o podem ser atendidas por meio de funcionalidades.<\/p>\n<p>Geralmente mensur\u00e1veis, os requisitos n\u00e3o funcionais definem caracter\u00edsticas e imp\u00f5em limites do sistema, como m\u00e9todo de desenvolvimento, tempo, espa\u00e7o, sistema operacional, dentre outros, cuja medida pode ser determinada. \u00c9 importante que se associe essa medida ou refer\u00eancia \u00e0 cada requisito n\u00e3o funcional.<\/p>\n<p>Para ficar mais claro, temos alguns exemplos de propriedades e suas m\u00e9tricas:<\/p>\n<ul>\n<li>O tamanho pode ser medido em kbytes e n\u00famero de Chip de RAM.<\/li>\n<li>A velocidade est\u00e1 ligada ao tempo de utiliza\u00e7\u00e3o da tela ou a transa\u00e7\u00f5es processadas por segundos.<\/li>\n<li>A m\u00e9trica da portabilidade \u00e9 o n\u00famero de sistema-alvo.<\/li>\n<li>A facilidade de uso pode ser medida pelo n\u00famero de janelas ou o tempo de treino.<\/li>\n<li>A confiabilidade tem liga\u00e7\u00e3o com o tempo m\u00e9dio que o sistema pode vir a falhar, a disponibilidade ou at\u00e9 mesmo a taxa de ocorr\u00eancia de falhas.<\/li>\n<\/ul>\n<p>Esses s\u00e3o apenas alguns dos exemplos em que as propriedades e m\u00e9tricas s\u00e3o associadas a cada requisito n\u00e3o funcional.<\/p>\n<p>Al\u00e9m do mais, esses requisitos n\u00e3o funcionais s\u00e3o divididos em tr\u00eas tipos principais: Requisitos de Produto Final; Requisitos Organizacionais; Requisitos Externos, que se dividem em diversos outros tipos.<\/p>\n<p>Listamos abaixo alguns exemplos b\u00e1sicos de requisitos n\u00e3o funcionais:<\/p>\n<ul>\n<li>Utiliza\u00e7\u00e3o do m\u00f3dulo de informa\u00e7\u00f5es cadastrais em modo off-line.<\/li>\n<li>O sistema deve ser implementado na linguagem Java.<\/li>\n<li>O sistema dever\u00e1 se comunicar com o banco SQL Server.<\/li>\n<li>Um relat\u00f3rio de supervis\u00e3o dever\u00e1 ser fornecido toda sexta-feira.<\/li>\n<li>O sistema deve ser execut\u00e1vel em qualquer plataforma.<\/li>\n<\/ul>\n<p>Muitos softwares n\u00e3o obt\u00eam sucesso e chegam a fracassar. Isso se d\u00e1 devido a n\u00e3o defini\u00e7\u00e3o pr\u00e9via desses atributos de qualidade na prioriza\u00e7\u00e3o ao definir uma arquitetura.<\/p>\n<p>Se esses requisitos n\u00e3o funcionais levantam aspectos t\u00e3o importantes nos sistemas de softwares e se desconsider\u00e1-los \u00e9 submeter-se a uma futura falta de \u00eaxito ou defici\u00eancia no desenvolvimento do software, qual o motivo de tanto descaso?<\/p>\n<p>Apenas as grandes empresas, nas quais existem uma equipe de TI com maior disposi\u00e7\u00e3o, em que acompanham de perto a elabora\u00e7\u00e3o dos softwares, \u00e9 que d\u00e3o credibilidade aos requisitos n\u00e3o funcionais.<\/p>\n<p>Eles s\u00e3o de dif\u00edcil estimativa tanto para prazo quanto trabalho ou custo.<\/p>\n<p>\u00c9 grande o n\u00famero de fornecedores que julgam \u201cgastar mais\u201d no desenvolvimento de app, por exemplo, ao lidarem com os requisitos n\u00e3o funcionais e s\u00f3 n\u00e3o os ignoram quando s\u00e3o solicitados explicitamente pelo cliente.<\/p>\n<p>De certo modo, todas as atividades que s\u00e3o relacionadas com os requisitos fazem parte do processo de \u201cengenharia de requisitos\u201d.<\/p>\n<p>Uma das \u00e1reas essenciais no desenvolvimento de softwares, a engenharia de requisitos possui algumas defini\u00e7\u00f5es segundo a literatura t\u00e9cnica da engenharia:<\/p>\n<ul>\n<li>Termo que descreve as atividades relacionadas cm a investiga\u00e7\u00e3o e defini\u00e7\u00e3o de escopo de um sistema de software.<\/li>\n<li>M\u00e9todo sistem\u00e1tico de desenvolvimento de requisitos por meio de um processo cooperativo de an\u00e1lise em que os resultados das observa\u00e7\u00f5es s\u00e3o codificados em uma variedade de formatos e a precis\u00e3o das observa\u00e7\u00f5es s\u00e3o verificadas frequentemente.<\/li>\n<li>Curso de descoberta, an\u00e1lise, documenta\u00e7\u00e3o e verifica\u00e7\u00e3o das fun\u00e7\u00f5es e restri\u00e7\u00f5es do sistema.<\/li>\n<\/ul>\n<h3>Regra de Neg\u00f3cio<\/h3>\n<p>Diferen\u00e7a de \u201crequisito funcional\u201d e \u201cregra de neg\u00f3cio\u201d \u00e9 algo comum na cabe\u00e7a de v\u00e1rios analistas de sistemas.<\/p>\n<p>Eu imagino que antes do lan\u00e7amento do microcomputador, o termo \u201cregra de neg\u00f3cio\u201d era algo interpretado totalmente isolado dos softwares empresariais, ou talvez nem fosse um termo conhecido pelas pessoas. Nos tempos atuais, \u00e9 dif\u00edcil encontrar algu\u00e9m que entenda regra de neg\u00f3cio como algo isolado do software.<\/p>\n<p>Quando se fala \u201cregra de neg\u00f3cio\u201d, praticamente sempre \u00e9 no contexto de um sistema.<\/p>\n<p>Estes dois conceitos (requisito funcional e regra de neg\u00f3cio) se encontram (se cruzam) a toda hora na modelagem de um sistema, mas s\u00e3o coisas diferentes.<\/p>\n<p>\u00c9 poss\u00edvel uma empresa mais arcaica viver sem software, mas mesmo essa empresa n\u00e3o consegue viver sem regras de neg\u00f3cio.<\/p>\n<p>As regras de neg\u00f3cio s\u00e3o restri\u00e7\u00f5es\/premissas necess\u00e1rias para o neg\u00f3cio \u201cacontecer\u201d. Poder\u00edamos elencar dezenas de regras de neg\u00f3cio, mas \u00e9 fundamental que seja claro que regras de neg\u00f3cio existe sem sistema, e que uma empresa n\u00e3o existe sem regras de neg\u00f3cio.<\/p>\n<h3>Diferen\u00e7a entre Requisito Funcional e Regra de Neg\u00f3cio<\/h3>\n<p>&nbsp;<\/p>\n<p>A diferen\u00e7a entre requisito funcional e regra de neg\u00f3cio, conceitualmente falando, \u00e9 que o requisito funcional se refere a \u201co que o sistema dever\u00e1 fazer\u201d, enquanto a regra de neg\u00f3cio refere-se a \u201ccomo o sistema dever\u00e1 fazer\u201d. Do ponto de vista do neg\u00f3cio (neg\u00f3cio do cliente para o qual o sistema est\u00e1 sendo feito), ambos s\u00e3o necessidades (requisito funcional e regra de neg\u00f3cio), mas cada uma com um foco diferente.<\/p>\n<p>Uma boa dica para saber o que \u00e9 regra de neg\u00f3cio \u00e9 perceber quando h\u00e1 condi\u00e7\u00f5es: \u201csomente, quando, requer, se, obrigat\u00f3rio, sempre\u201d. Requisitos n\u00e3o possuem condi\u00e7\u00f5es, regras \u201cs\u00e3o\u201d condi\u00e7\u00f5es. Requisitos s\u00e3o a\u00e7\u00f5es objetivas, desejo, solicita\u00e7\u00e3o.<\/p>\n<h3>Atributos de uma boa Regra de Neg\u00f3cio<\/h3>\n<p>&nbsp;<\/p>\n<p>Uma regra de neg\u00f3cio com qualidade precisa atender a alguns atributos espec\u00edficos. Na literatura, tanto nacional quanto estrangeira, n\u00e3o h\u00e1 material que especifique esses atributos.<\/p>\n<p>Entretanto, devido \u00e0 estrutura sint\u00e1tica de uma regra de neg\u00f3cio ser muito semelhante \u00e0 de um requisito funcional, elencamos alguns atributos (alguns comuns aos requisitos funcionais) a serem considerados na especifica\u00e7\u00e3o de uma regra de neg\u00f3cio.<\/p>\n<p>A seguir a lista dos atributos que considero relevantes.<\/p>\n<table style=\"border-color: #000000;\" border=\"1\">\n<tbody>\n<tr>\n<td width=\"132\"><strong>Atributo<\/strong><\/td>\n<td width=\"434\"><strong>Referente a<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"132\">Unidade<\/td>\n<td width=\"434\">A regra de neg\u00f3cio deve propor\/viabilizar uma \u00fanica coisa apenas. N\u00e3o deve atender a mais de uma restri\u00e7\u00e3o. A regra de neg\u00f3cio \u201cc\u00e1lculo de sal\u00e1rio\u201d n\u00e3o \u00e9 unit\u00e1ria, pois se refere implicitamente ao c\u00e1lculo de qualquer tipo de sal\u00e1rio; e, em qualquer empresa, existem formas diferentes de calcular sal\u00e1rio (para profissional ativo, aposentado, estagi\u00e1rio, efetivo, licenciado etc.). Esta regra de neg\u00f3cio assume assim v\u00e1rias responsabilidades, quando deveria assumir apenas uma.<\/td>\n<\/tr>\n<tr>\n<td width=\"132\">Completude<\/td>\n<td width=\"434\">A regra de neg\u00f3cio deve ser autocontida, deve ter \u201cin\u00edcio\/meio\/fim\u201d, ser completa. A regra de neg\u00f3cio \u201cc\u00e1lculo de sal\u00e1rio\u201d n\u00e3o \u00e9 completa, s\u00f3 conta \u201cparte da est\u00f3ria\u201d. Para ser completa, deveria ser algo como \u201cc\u00e1lculo de sal\u00e1rio para profissionais afastados h\u00e1 mais de 15 dias\u201d.<\/td>\n<\/tr>\n<tr>\n<td width=\"132\">Consist\u00eancia<\/td>\n<td width=\"434\">N\u00e3o deve contradizer outra regra de neg\u00f3cio do mesmo escopo do projeto. \u00c9 como termos duas regras de neg\u00f3cios se propondo a fazer uma mesma coisa, mas cada regra de neg\u00f3cio se propondo a fazer essa coisa de formas diferentes.<\/td>\n<\/tr>\n<tr>\n<td width=\"132\">Atomicidade<\/td>\n<td width=\"434\">Uma regra de neg\u00f3cio para ser at\u00f4mica precisa tamb\u00e9m ter unidade, pois atomicidade remete a assumir apenas uma responsabilidade. No entanto, tamb\u00e9m, deve ser indivis\u00edvel, n\u00e3o podendo ser decomposta. Muitas regras de neg\u00f3cios possuem conjun\u00e7\u00e3o, dependem de outras para se realizar. Onde temos duas regras de neg\u00f3cios, como: \u201ccalcular juros para pagamento atrasado\u201d e \u201cincluir juros para pagamentos de financiamento imobili\u00e1rio atrasados\u201d, na realidade, se pensarmos em atomicidade, temos uma \u00fanica regra de neg\u00f3cio que \u00e9 \u201ccalcular juros para pagamentos atrasados de financiamento imobili\u00e1rio\u201d.<\/td>\n<\/tr>\n<tr>\n<td width=\"132\">N\u00e3o Ambiguidade<\/td>\n<td width=\"434\">N\u00e3o pode ser amb\u00edgua, definir algo que n\u00e3o fica claro o que \u00e9. A regra de neg\u00f3cio \u201ccrit\u00e9rios para processamento de faturas\u201d \u00e9 amb\u00edgua. Fatura de qu\u00ea? Crit\u00e9rios para processar o qu\u00ea? \u201cCrit\u00e9rios para processamento de fatura de mensalidade\u201d j\u00e1 \u00e9 melhor, mas ainda \u00e9 ruim. Mensalidade de qu\u00ea? Seria n\u00e3o amb\u00edguo se n\u00e3o deixasse d\u00favidas, algo como \u201ccrit\u00e9rios para processamento de faturas de mensalidades de alunos do segundo grau\u201d ou \u201ccrit\u00e9rios para processamento de faturas de mensalidades de qualquer aluno impendente de s\u00e9rie\u201d.<\/td>\n<\/tr>\n<tr>\n<td width=\"132\">Verific\u00e1vel<\/td>\n<td width=\"434\">N\u00e3o adianta ter uma regra de neg\u00f3cio se ela n\u00e3o \u00e9 palp\u00e1vel, poss\u00edvel de associar com um requisito funcional que ser\u00e1 constru\u00eddo, testado etc. Uma regra de neg\u00f3cio tem que ser test\u00e1vel, tem que ser poss\u00edvel atestar que ela foi atendida por meio de algum requisito funcional. Para isso, tem que ser tamb\u00e9m rastre\u00e1vel.<\/td>\n<\/tr>\n<tr>\n<td width=\"132\">Rastre\u00e1vel<\/td>\n<td width=\"434\">Deve ser poss\u00edvel achar a regra de neg\u00f3cio no sistema pronto. Como saber se uma regra de neg\u00f3cio foi atendida? Para isso, \u00e9 necess\u00e1rio ter rastreabilidade, e isso s\u00f3 \u00e9 poss\u00edvel ligando as pontas (associar a regra de neg\u00f3cio ao requisito funcional, associar o requisito funcional \u00e0 interface gr\u00e1fica, que ser\u00e1 associada a um caso de uso, que ser\u00e1 associado a funcionalidades, que ser\u00e3o implementadas etc.).<\/td>\n<\/tr>\n<tr>\n<td width=\"132\">Exemplific\u00e1vel<\/td>\n<td width=\"434\">Muitas regras de neg\u00f3cios tratam de c\u00e1lculos, f\u00f3rmulas, algoritmos etc. Uma regra de neg\u00f3cio deve poder ser exemplificada fora do contexto do sistema, para assim facilitar o entendimento de seu escopo pelos profissionais que a implementar\u00e3o\/validar\u00e3o.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Um detalhe importante \u00e9 que uma regra de neg\u00f3cio n\u00e3o possui prioridade. Como uma regra de neg\u00f3cio, no contexto de um sistema, somente existe se associada a um ou a mais requisitos funcionais, a prioridade aplicada \u00e0 regra de neg\u00f3cio ser\u00e1 a prioridade aplicada ao requisito que depende dela.<\/p>\n<h3>Estrutura de uma Regra de Neg\u00f3cio<\/h3>\n<p>N\u00e3o h\u00e1 um padr\u00e3o estabelecido sobre a estrutura de uma regra de neg\u00f3cio. Contudo, a maioria utiliza um formato semelhante, contendo campos espec\u00edficos. O modelo a seguir contempla os campos mais relevantes, com posterior descri\u00e7\u00e3o de cada um.<\/p>\n<table style=\"border-color: #000000;\" border=\"1\">\n<tbody>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Identificador<\/td>\n<td colspan=\"3\" width=\"425\"><\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Nome<\/td>\n<td colspan=\"3\" width=\"425\"><\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">M\u00f3dulo<\/td>\n<td colspan=\"3\" width=\"425\"><\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Data de cria\u00e7\u00e3o<\/td>\n<td width=\"142\"><\/td>\n<td style=\"border-color: #dbdbdb;\" width=\"142\">Autor<\/td>\n<td width=\"142\"><\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Data da altera\u00e7\u00e3o<\/td>\n<td width=\"142\"><\/td>\n<td style=\"border-color: #dbdbdb;\" width=\"142\">Autor<\/td>\n<td width=\"142\"><\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Vers\u00e3o<\/td>\n<td width=\"142\"><\/td>\n<td style=\"border-color: #dbdbdb;\" width=\"142\">Depend\u00eancias<\/td>\n<td width=\"142\"><\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Descri\u00e7\u00e3o<\/td>\n<td colspan=\"3\" width=\"425\"><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>Explicando cada campo<\/p>\n<table style=\"border-color: #000000;\" border=\"1\">\n<tbody>\n<tr>\n<td width=\"104\"><strong>Campo<\/strong><\/td>\n<td width=\"463\"><strong>Descri\u00e7\u00e3o<\/strong><\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Identificador<\/td>\n<td width=\"463\">Sufixo seguido de um identificador \u00fanico. O sufixo geralmente utilizado \u00e9 regra de neg\u00f3cio (regra de neg\u00f3cio), e o identificador \u00fanico geralmente \u00e9 composto de quatro d\u00edgitos (podendo ser mais, conforme a o tamanho do sistema que est\u00e1 sendo especificado).<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Nome<\/td>\n<td width=\"463\">Nome curto da regra de neg\u00f3cio, mas que possibilite entender bem o que regra de neg\u00f3cio faz apenas pelo nome.<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">M\u00f3dulo<\/td>\n<td width=\"463\">M\u00f3dulo ao qual o requisito funcional pertence. Se for um sistema pequeno que n\u00e3o possua nenhum m\u00f3dulo, somente o pr\u00f3prio sistema, deve ser preenchido com N\/A (n\u00e3o se aplica).<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Data de cria\u00e7\u00e3o<\/td>\n<td width=\"463\">Data da cria\u00e7\u00e3o da regra de neg\u00f3cio, ou a data em que ela foi especificada.<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Autor<\/td>\n<td width=\"463\">Profissional que especificou a regra de neg\u00f3cio pela primeira vez, quem a criou.<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Data da \u00faltima altera\u00e7\u00e3o<\/td>\n<td width=\"463\">Data em que houve a \u00faltima altera\u00e7\u00e3o na regra de neg\u00f3cio.<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Autor<\/td>\n<td width=\"463\">Profissional que alterou a especifica\u00e7\u00e3o da regra de neg\u00f3cio pela \u00faltima vez.<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Vers\u00e3o<\/td>\n<td width=\"463\">N\u00famero da vers\u00e3o da regra de neg\u00f3cio. Geralmente utiliza-se algo simples, como 1, 2 etc. A vers\u00e3o inicial sempre \u00e9 a 1, e a cada altera\u00e7\u00e3o, incrementa-se a vers\u00e3o (na cria\u00e7\u00e3o vers\u00e3o 1, na primeira altera\u00e7\u00e3o vers\u00e3o 2 etc.).<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Depend\u00eancias<\/td>\n<td width=\"463\">Quais requisitos funcionais s\u00e3o dependentes da regra de neg\u00f3cio para serem realizados. Coloca-se apenas o identificador dos requisitos funcionais.<\/td>\n<\/tr>\n<tr>\n<td width=\"104\">Descri\u00e7\u00e3o<\/td>\n<td width=\"463\">Descri\u00e7\u00e3o detalhada (a mais detalhada poss\u00edvel) da regra de neg\u00f3cio.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>Exemplo de uma Regra de Neg\u00f3cio especificada<\/p>\n<table style=\"border-color: #000000;\" border=\"1\">\n<tbody>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Identificador<\/td>\n<td colspan=\"3\" width=\"425\">RN0101<\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Nome<\/td>\n<td colspan=\"3\" width=\"425\">Valida\u00e7\u00e3o da identifica\u00e7\u00e3o da pessoa que solicita a retirada\/entrega do material<\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">M\u00f3dulo<\/td>\n<td colspan=\"3\" width=\"425\">Gest\u00e3o de Armaz\u00e9ns<\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Data de cria\u00e7\u00e3o<\/td>\n<td width=\"142\">01\/04\/2018<\/td>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Autor<\/td>\n<td width=\"142\">Paulo<\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Data da altera\u00e7\u00e3o<\/td>\n<td width=\"142\">N\/A<\/td>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Autor<\/td>\n<td width=\"142\">N\/A<\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Vers\u00e3o<\/td>\n<td width=\"142\">1.0<\/td>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Depend\u00eancias<\/td>\n<td width=\"142\">RN0099<\/td>\n<\/tr>\n<tr>\n<td style=\"background-color: #dbdbdb;\" width=\"142\">Descri\u00e7\u00e3o<\/td>\n<td colspan=\"3\" width=\"425\">Sempre que uma pessoa se dirigir ao departamento de expedi\u00e7\u00e3o para solicitar uma mercadoria, ela deve se identificar com seu documento de identidade. O profissional do departamento de expedi\u00e7\u00e3o deve certificar-se que o documento \u00e9 v\u00e1lido.<\/p>\n<p>Para validar o documento fornecido pelo solicitante, o seu n\u00famero dever\u00e1 ser validado no sistema da Secretaria de Seguran\u00e7a P\u00fablica do Estado de S\u00e3o Paulo, por meio de funcionalidade correspondente no m\u00f3dulo de controle de expedi\u00e7\u00e3o. Se o documento n\u00e3o tiver como \u00f3rg\u00e3o emissor SSP-SP, n\u00e3o precisar\u00e1 ser validado, mas dever\u00e1 ser microfilmado e ter uma c\u00f3pia armazenada no sistema, por meio de funcionalidade espec\u00edfica.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<h3>Software Livre<\/h3>\n<p>As duas principais organiza\u00e7\u00f5es internacionais respons\u00e1veis pela prote\u00e7\u00e3o e promo\u00e7\u00e3o do software livre, a Free Software Foundation (FSF)e a Open Source Initiative (OSI), atuam tamb\u00e9m para garantir que os termos Free Software e Open Source sejam utilizados de forma correta. A FSF considera um software como livre quando atende a quatro tipos de liberdade para os usu\u00e1rios:<\/p>\n<ol>\n<li>A liberdade de executar o programa, para qualquer prop\u00f3sito;<\/li>\n<li>A liberdade de estudar o programa, e adapt\u00e1-lo para as suas necessidades;<\/li>\n<li>A liberdade de redistribuir c\u00f3pias do programa de modo que voc\u00ea possa ajudar ao seu pr\u00f3ximo;<\/li>\n<li>A liberdade de modificar (aperfei\u00e7oar) o programa e distribuir estas modifica\u00e7\u00f5es, de modo que toda a comunidade se beneficie.<\/li>\n<\/ol>\n<p>Lembrando que o acesso ao c\u00f3digo-fonte \u00e9 um pr\u00e9-requisito para as liberdades 1 e 3, uma vez que n\u00e3o \u00e9 poss\u00edvel estudar ou adaptar o programa sem acessar o c\u00f3digo-fonte.<\/p>\n<p>Para que as quatro liberdades sejam satisfeitas, \u00e9 necess\u00e1rio que o programa seja distribu\u00eddo com o seu c\u00f3digo-fonte e que n\u00e3o sejam colocadas restri\u00e7\u00f5es para que os usu\u00e1rios alterem e redistribuam esse c\u00f3digo. Segundo a Free Software Foundation, \u00e9 comum que a comunidade de usu\u00e1rios confunda softwares gratuitos (freewares) com softwares livres. No entanto, a funda\u00e7\u00e3o enfatiza que h\u00e1 um grande equ\u00edvoco nisso e que usu\u00e1rios devem entender que um software livre \u2013 ao contr\u00e1rio de um software gratuito \u2013 \u00e9 aquele que respeita a liberdade e o senso de comunidade dos usu\u00e1rios. Dessa forma, um software livre tem como marcante a caracter\u00edstica de dar ao usu\u00e1rio a liberdade de copiar, distribuir, modificar e estudar o programa sem pagar ou pedir permiss\u00e3o ao autor. Para garantir essas liberdades, o software livre garante aos seus usu\u00e1rios acesso a seu c\u00f3digo-fonte. Diferentemente disso, um software gratuito \u00e9 apenas um programa gratuitamente copiado e distribu\u00eddo em sua forma execut\u00e1vel, n\u00e3o podendo ser modificado ou estudado dada a aus\u00eancia do fornecimento do c\u00f3digo-fonte. . Isso significa que um desenvolvedor que distribuir um software livre pode cobrar por isso ou fornecer o software de maneira gratuita.<\/p>\n<h3><a name=\"_Toc3114849\"><\/a>Relato de experi\u00eancia:<\/h3>\n<p>Segundo Andr\u00e9 Luiz de Almeida, ex-diretor de Tecnologia da Informa\u00e7\u00e3o da Secretaria de Sa\u00fade de S\u00e3o Paulo:<\/p>\n<blockquote><p><em>\u201cDurante anos \u00e0 frente de um departamento de tecnologia da informa\u00e7\u00e3o, diversos processos de aquisi\u00e7\u00e3o foram encabe\u00e7ados, dos mais diversos tipos, e com o tempo, veio a experi\u00eancia, e relatarei agora as principais li\u00e7\u00f5es aprendidas:<\/em><\/p>\n<h3><em>Software de Prateleira<\/em><\/h3>\n<p><em>A aquisi\u00e7\u00e3o de software de prateleira era um processo relativamente simples, quase sempre contava com competitividade no ponto de vista de se ter sempre mais de uma empresa fornecendo aquele produto, pois as multinacionais que fornecem o software raramente fazem uma oferta, elas deixam esse trabalho por conta das suas distribuidoras e revendas, contudo, com a nova resolu\u00e7\u00e3o do TCU que pro\u00edbe o modelo anterior, todo o processo de aquisi\u00e7\u00e3o est\u00e1 passando por adapta\u00e7\u00f5es. Essas adapta\u00e7\u00f5es s\u00e3o extremamente v\u00e1lidas, basta consultar o documento da TCU (Ac\u00f3rd\u00e3o 2.569\/2018) os valores que essas empresas receberam dos \u00f3rg\u00e3os p\u00fablicos. Na sua ess\u00eancia, o que muda \u00e9 que n\u00e3o \u00e9 mais permitido pagar por licen\u00e7as que n\u00e3o est\u00e3o em uso, coisa que era feito quase que como praxe no processo de aquisi\u00e7\u00e3o. Sempre se dimensiona o parque com algum crescimento e essas licen\u00e7as de uso eram adquiridas e pagas e as vezes ficavam fora de utiliza\u00e7\u00e3o por muito tempo.<\/em><\/p>\n<p><em>Vale observar que a escolha de um software \u00e9 sempre um processo muito delicado, especialmente se esse software for destinado para as esta\u00e7\u00f5es de trabalho. Imagine num cen\u00e1rio hipot\u00e9tico a instala\u00e7\u00e3o de um antiv\u00edrus, instalar em um computador \u00e9 uma tarefa relativamente simples e tranquila, agora imagine fazer isso em uma rede de mais de 10.000 computadores? Qual a log\u00edstica para isso? Como conseguir atacar todas as esta\u00e7\u00f5es? Essas s\u00e3o quest\u00f5es que impactam muito na opera\u00e7\u00e3o, mas h\u00e1 diversos pontos al\u00e9m do fato da mudan\u00e7a na esta\u00e7\u00e3o de trabalho. Imagine o impacto de se trocar um software de backup corporativo que pode fazer com que todo o conjunto de fitas anteriores sejam reprocessadas.<\/em><\/p>\n<p><em>Pontos de maior aten\u00e7\u00e3o na escolha de um software s\u00e3o:<\/em><\/p>\n<p><em>Continuidade \u2013 Garanta na documenta\u00e7\u00e3o que o software receber\u00e1 atualiza\u00e7\u00f5es por um per\u00edodo adequado. <\/em><\/p>\n<p><em>Adequa\u00e7\u00e3o a sua plataforma \u2013 Deixe claro na documenta\u00e7\u00e3o como \u00e9 composto seu parque de computadores detalhando mem\u00f3ria, sistema operacional, log\u00edstica de instala\u00e7\u00e3o e requerimentos de acesso a instala\u00e7\u00e3o (imagine instalar um upgrade em computadores que est\u00e3o em hospitais, h\u00e1 a necessidade de planejamento pr\u00e9vio).<\/em><\/p>\n<p><em>N\u00edvel de suporte esperado \u2013 Em caso de problemas qual o canal a ser acessado e em quanto tempo haver\u00e1 apoio na sua opera\u00e7\u00e3o.<\/em><\/p>\n<h3><em>Requisitos n\u00e3o Funcionais<\/em><\/h3>\n<p><em>Essa defini\u00e7\u00e3o \u00e9 uma das partes mais negligenciadas no desenvolvimento de software quando feito por terceiros e as consequ\u00eancias desta neglig\u00eancia podem ser determinantes no sucesso do projeto. Imagine o cen\u00e1rio onde todo o software foi feito de forma que para ser execut\u00e1vel h\u00e1 a necessidade do investimento de monta consider\u00e1vel para aquisi\u00e7\u00e3o de um novo hardware ou que use um banco de dados que n\u00e3o \u00e9 suportado por este \u00f3rg\u00e3o. <\/em><\/p>\n<p><em>Esse conjunto de defini\u00e7\u00f5es claramente computacionais passam por especifica\u00e7\u00f5es t\u00e9cnicas que devem estar atentas a altera\u00e7\u00f5es de mercado, um exemplo de um problema recente foi a finaliza\u00e7\u00e3o dos sistemas operacionais de 32 bits para esta\u00e7\u00f5es de trabalho. V\u00e1rios sistemas criados em tempos anteriores n\u00e3o ficaram atentos a esse tipo de mudan\u00e7a e hoje pode haver esta\u00e7\u00f5es de trabalho sem possibilidade de atualiza\u00e7\u00e3o pois h\u00e1 um aplicativo desenvolvido que s\u00f3 tem execu\u00e7\u00e3o prevista em ambiente de 32 bits.<\/em><\/p>\n<h3><em>Regras de Neg\u00f3cio<\/em><\/h3>\n<p><em>Se existe alguma parte do desenvolvimento de software que menos se pare\u00e7a com uma ci\u00eancia exata \u00e9 o levantamento das regras de neg\u00f3cio. Nessa etapa, \u00e9 fundamental que o entrevistador tenha a perspic\u00e1cia de conseguir entender os meandros pelo qual est\u00e1 caminhando. N\u00e3o \u00e9 incomum durante uma entrega haver uma discrep\u00e2ncia entre o que foi solicitado e o que foi entregue. \u00c9 exatamente essa etapa de entendimento das regras de neg\u00f3cios e requisitos funcionais que deve diminuir essa ocorr\u00eancia. Uma das melhores pr\u00e1ticas para se mitigar essa ocorr\u00eancia \u00e9 que depois de levantado o requisito o documento de requisito volte para o entrevistado para que ele possa ler e confirmar que a necessidade est\u00e1 totalmente expressa no documento de regra de neg\u00f3cio. Isto feito, ainda na tentativa de diminuir a discrep\u00e2ncia entre o solicitado e o entregue \u00e9 uma boa pr\u00e1tica solicitar ao gerente ou respons\u00e1vel da \u00e1rea que destaque um outro revisor. Esta etapa tenta eliminar o vi\u00e9s de olhar \u00fanico, tentando assim atender de forma mais global e n\u00e3o somente a um interlocutor.<\/em><\/p>\n<p><em>Esse compartilhamento de responsabilidade na montagem das regras de neg\u00f3cio, sempre que poss\u00edvel, requer um passo final que \u00e9 o compartilhamento e a publicidade do documento de requisito com o gerente\/respons\u00e1vel pela \u00e1rea final, uma vez definido o requisito\/regra, validado com outro usu\u00e1rio, \u00e9 fundamental que copias assinadas sejam enviados ao respons\u00e1vel da \u00e1rea.\u201d.<\/em><\/p><\/blockquote>\n<h3><a name=\"_Toc536451402\"><\/a>Resumo \u2013 Principais Pontos de Aten\u00e7\u00e3o<\/h3>\n<ul>\n<li>Ao se contratar o software, tome cuidado com a instala\u00e7\u00e3o e com sua manuten\u00e7\u00e3o, entenda qual o ambiente necess\u00e1rio e, caso seja pertinente, mantenha um ambiente de homologa\u00e7\u00e3o e teste do software;<\/li>\n<li>Entenda o modelo de licenciamento do software que est\u00e1 adquirindo ou usando. Podem haver restri\u00e7\u00f5es funcionais e n\u00e3o funcionais;<\/li>\n<li>Observe se existe algum padr\u00e3o j\u00e1 criado por uma unidade central, se existir, respeite-o;<\/li>\n<li>Aprenda a contar pontos de fun\u00e7\u00e3o e compartilhe com seu fornecedor a forma com que ser\u00e1 feita a contagem. Essa forma deve estar pactuada entre as partes. O TCU tem uma cartilha de contagem que pode ser a refer\u00eancia comum;<\/li>\n<li>Contratos por ponto de fun\u00e7\u00e3o s\u00e3o de dif\u00edcil administra\u00e7\u00e3o, mas garantem uma entrega no fim do processo;<\/li>\n<li>Contratos por homem-hora s\u00e3o de f\u00e1cil administra\u00e7\u00e3o, mas n\u00e3o garantem uma entrega final, podem ser facilmente desvirtuados com outras finalidades;<\/li>\n<li>Uma especifica\u00e7\u00e3o com requisito de software adequado \u00e9 fundamental para sucesso, entenda e aplique seus princ\u00edpios;<\/li>\n<li>N\u00e3o negligencie a especifica\u00e7\u00e3o n\u00e3o funcional, ela \u00e9 a chave tecnol\u00f3gica para o desenvolvimento do software;<\/li>\n<li>As regras de neg\u00f3cio devem ser colhidas e revisadas com a \u00e1rea final, preferencialmente com mais de um usu\u00e1rio da \u00e1rea;<\/li>\n<li>O respons\u00e1vel da \u00e1rea fim deve receber todos os documentos de regras de neg\u00f3cio para ci\u00eancia;<\/li>\n<li>Software livre n\u00e3o \u00e9 sin\u00f4nimo de software gr\u00e1tis, nem software gr\u00e1tis pode ser utilizado em qualquer ambiente como uma estrutura de governo.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2><a name=\"_Toc3185579\"><\/a>ANEXOS<\/h2>\n<p>Disponibilizamos a seguir alguns exemplos de editais e termos de refer\u00eancia que podem ser \u00fateis:<\/p>\n<ul>\n<li><a href=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Anexo1.pdf\"><span style=\"color: #000000;\">Edital Base para Antiv\u00edrus<\/span><\/a><\/li>\n<li><a href=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Anexo2.pdf\"><span style=\"color: #000000;\">Edital Base para Banco de Dados<\/span><\/a><\/li>\n<li><a href=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Anexo3.pdf\"><span style=\"color: #000000;\">Edital Base para Ponto de Fun\u00e7\u00e3o<\/span><\/a><\/li>\n<li><a href=\"http:\/\/www.conass.org.br\/guiainformacao\/wp-content\/uploads\/2019\/10\/Anexo4.pdf\"><span style=\"color: #000000;\">Edital base para Homem-Hora<\/span><\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Introdu\u00e7\u00e3o Neste segundo cap\u00edtulo, o principal objetivo \u00e9 demostrar aos gestores que a contrata\u00e7\u00e3o de software se divide em dois grandes grupos: os aplicativos de prateleira e o desenvolvimento de aplicativos espec\u00edficos, personalizados e com foco em atendimento de demandas n\u00e3o encontradas. Vamos Falar de Software Existem diversas defini\u00e7\u00f5es t\u00e9cnicas para o que \u00e9 software, [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":0,"menu_order":110,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"class_list":["post-18494","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/pages\/18494","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/comments?post=18494"}],"version-history":[{"count":2,"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/pages\/18494\/revisions"}],"predecessor-version":[{"id":18506,"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/pages\/18494\/revisions\/18506"}],"wp:attachment":[{"href":"https:\/\/www.conass.org.br\/guiainformacao\/wp-json\/wp\/v2\/media?parent=18494"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}