Capítulo 2 – Orientações para a elaboração e especificação das regras de negócio para a contratação de serviços ou aquisição de soluções de TI (aplicativos ou sistemas informatizados) para a gestão estadual do SUS

topo

Introdução

Neste segundo capítulo, o principal objetivo é demostrar aos gestores que a contratação de software se divide em dois grandes grupos: os aplicativos de prateleira e o desenvolvimento de aplicativos específicos, personalizados e com foco em atendimento de demandas não encontradas.

Vamos Falar de Software

Existem diversas definições técnicas para o que é software, variando desde a mais simples, que separa a parte física da parte lógica dos componentes de um ambiente computacional em que a parte lógica ganha esse nome, até uma das mais difundidas, que classifica como uma sequência de instruções a serem seguidas, manipuladas ou ainda executadas por um computador.

Por sua existência imaterial, ela é de difícil entendimento ou enquadramento em alguns momentos. A grande maioria das empresas entende que um software é um bem de capital, logo, faz parte do processo de valoração de uma empresa, consta como um ativo e tem depreciação. Outra leitura – e essa muito aceita, especialmente nas unidades governamentais – entende que um software é um bem de consumo, ou seja, é um serviço a ser prestado. Essa posição adotada por diversos órgãos de governo que divergem da opinião geral do mercado se baseia em alguns aspectos importantes de comportamento. Os mais relevantes para a questão pública são: a incapacidade de colocar um número de patrimônio, como um bem, conforme prevê a Lei 4.320/1964, que diz que todos os bens adquiridos pelos órgãos da administração pública devem ter seu referido controle patrimonial; como também a necessidade de licenciamento anual, que obriga um novo desembolso para um bem já adquirido para continuar se utilizando dele com plena capacidade e o mantendo atualizado.

O mundo do software pode ser facilmente dividido em dois grandes grupos que têm características similares de funcionamento: destinações diferenciadas de objeto e fluxos de aquisição extremamente distintos. Apesar de não prevista em lei, a jurisprudência administrativa federal e estadual vem cada vez mais ratificando o entendimento que, para fins tributários e de aquisição, existem dois tipos básicos de programa de computador, o “software Personalizado” e o “software de prateleira”, que receberão tratamento tributário distinto (serviço ou mercadoria) em razão da forma de sua produção e comercialização.

O reconhecimento pela jurisprudência de dois tipos básicos de programa de computador (personalizado e prateleira) ficou consolidado em 1998, após o julgamento pelo STF do Recurso Extraordinário nº 176626 (rel. Min. Sepúlveda Pertence).

O “software personalizado” é comumente definido pela jurisprudência como “programa de computador produzido sob encomenda para atender a necessidade específica de determinado usuário”, enquanto o “software de prateleira” é definido como “programa de computador produzido em larga escala de maneira uniforme e colocado no mercado para aquisição por qualquer interessado sob a forma de cópias múltiplas”.

A Lei do Software (Lei nº 9.609/98) conceitua o programa de computador da seguinte maneira:

Art. 1º – Programa de computador é a expressão de um conjunto organizado de instruções em linguagem natural ou codificada, contida em suporte físico de qualquer natureza, de emprego necessário em máquinas automáticas de tratamento da informação, dispositivos, instrumentos ou equipamentos periféricos, baseados em técnica digital ou análoga, para fazê-los funcionar de modo e para fins determinados.

Como se vê, previu-se que todo programa de computador (instruções) estaria gravado em um suporte físico de qualquer natureza (o que atualmente nem sempre acontece), ainda assim, esta conceituação dá base ao entendimento de que o programa de computador, quando gravado em um suporte físico, é um bem imaterial (incorpóreo) quanto ao programa (dados ou instruções) e bem material (corpóreo) quanto ao suporte físico como o compact disc ou memória flash.

A legislação equipara o programa de computador às obras intelectuais (fruto da intelectualidade humana), determinando que é necessário possuir autorização do autor como os contratos de licença para sua utilização.

Software de Prateleira

O software de prateleira é aquele que já está pronto para uso e que, na prática, teria um custo de desenvolvimento muito maior do que utilizar algo que está comercialmente disponível. Volta-se a recordar que a legislação brasileira para software equipara programas para computador com obras intelectuais, logo protegidas pela lei de propriedade intelectual, Lei 9279/96. São exemplos de software de prateleira:

Todos esses softwares de prateleira têm atrelado a si um contrato de licença de uso que dá todo suporte legal, define os direitos e os deveres do contratante deste software. Por vezes, esse documento altamente importante é resumido com um simples clique depois da expressão “Eu Aceito”.

Esse contrato de licença de software pode ser uma licença comercial ou uma licença livre. Neste momento, vamos tratar aqui do aspecto comercial e como ele impacta no processo de seleção e contratação, enquanto o aspecto da licença livre será tratado no tópico de Software Livre.

Licença Comercial

O termo licença comercial é normalmente associado e designado a contratos de licenciamento de uso de software para o funcionamento empresarial. Os softwares chamados comerciais são aqueles pelos quais o usuário paga uma taxa de licenciamento para poder utilizá-los.

É importante observar que, de acordo com o modelo de licenciamento de software comercial, o que o usuário adquire quando paga pelo software é o direito de utilizá-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á se adquirindo a mídia impressa, mas o direito autoral do conteúdo é do autor ou da editora.

As duas restrições mais comuns nas licenças comerciais são:

A Licença comercial define também, em muitos casos, os serviços que a empresa que vende o software disponibiliza para os usuários que adquirem seu direito de uso, tais como suporte, correção de erros de funcionamento, atualização periódica e acesso a documentação de uso e outros materiais – normalmente via Internet.

Especificação

A etapa mais importante de qualquer processo de aquisição de produto ou serviço é a especificação técnica que deverá estar contida no processo licitatório. Ela é um marco da sua necessidade evidente e é 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ão há mais de um fornecedor, haverá sempre mais de uma empresa habilitada a poder vender praticando ofertas diferenciadas.

São pontos comuns da especificação de software de prateleira:

Suporte Técnico

Atendimento realizado pelo fabricante para tratar de eventuais problemas no funcionamento do software em decorrência de falhas de engenharia do produto ou para dirimir dúvidas sobre o uso do produto. Difere de outros serviços que podem ser prestados por revendedores, ou pelo próprio fabricante, que têm caráter de consultoria ou de atendimento técnico para intervir no ambiente computacional para resolver situações decorrentes de mau uso do software.

Para suporte técnico, é fundamental que seja claro no documento de especificação que tipo de suporte técnico é esperado e, da mesma forma que falaremos em hardware, é primordial que se especifique o tempo, seja para o primeiro atendimento, seja para a solução do problema. Recomendamos sempre pensar em tempo de solução, pois aí se tem, de fato, o objeto referente ao chamado técnico resolvido. Outro aspecto essencial no item de suporte técnico é identificar de que forma ele ocorrerá, pois não será incomum a necessidade de abrir um chamado no fabricante usando a língua inglesa; se isso for um empecilho, é mandatório que fique claro no item de suporte técnico a língua que será utilizada para contatar a central de atendimento.

É mandatório também especificar por quanto tempo se deseja que o suporte seja válido.

Manutenção do Software

Disponibilização, 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 é aplicado sobre uma determinada versão.

Na questão de manutenção de software, é mandatório que a continuidade do produto seja clara, pois um investimento maior que o da aquisição é o da substituição de uma plataforma que será descontinuada. Todo fabricante de software disponibiliza, mesmo que para uso interno, um “roadmap” do produto, com o planejamento de aprimoramento da plataforma, mudanças significativas de arquitetura e novas capacidades. É nesse documento que, por exemplo, consegue-se mapear a eliminação de alguma plataforma computacional que pode ser relevante para a utilização do produto, como, por exemplo, a extinção de uma plataforma em 32 bits.

É mandatório também especificar por quanto tempo se deseja que a manutenção de software seja válida.

Instalação

Disponibilização, por parte do fabricante ou do seu representante autorizado, de implantação completa do software, ou parcial, de forma que entreguem uma nova versão estável do produto. Podem, também, incluir as aplicações das correções de comportamentos disfuncionais que não tenham sido corrigidos por manutenções anteriores do software, por critério do contratante.

Neste ponto, é fundamental que seja pensada pelo contratante a possibilidade de transferência de tecnologia. Essa etapa diminui consideravelmente a dependência do fornecedor e empodera a equipe de tecnologia a utilizar mais plenamente o software.

Caso deseje a instalação do software, é providencial que haja o planejamento para uma etapa de inspeção nas dependências onde será feita a instalação. Nesse momento, deve ser apresentado o hardware no qual será feita a instalação. Somente empresas que passem e apresentem o documento de comparecimento na inspeção ou visita técnica estarão habilitadas a continuar o processo licitatório.

Após os itens que são gerais a todos os softwares de prateleira, como suporte, manutenção e instalação, segue uma sequência de especificações que deixam claro o objeto da aquisição. Não é incomum haver diversos fornecedores para um bem comum como software de prateleira, por isso, a caracterização específica do seu software é tão importante, mas também é importante manter sempre o princípio da imparcialidade na escolha. Por mais que haja um ajuste mental de que a marca “A” é melhor que a marca “B”, não havendo motivo técnicos claros para estabelecer a diferença entre elas, ambas devem ser consideradas para o processo licitatório.

Essa talvez seja a parte mais delicada do trabalho de elaboração, visto que ela consome tempo, muito tempo, mas, se bem feita, pode resolver inúmeros problemas para a administração. Ouso dizer que o segredo está no equilíbrio das demandas em que todas as necessidades técnicas estão colocadas; e a quantidade de fornecedores coberta pela proposta maximiza a concorrência, gerando assim economia ao erário público.

Principais categorias de software de prateleira e suas principais características:

Antivírus

Essa é uma das categorias que mais tem fornecedores e na qual é esperada uma concorrência acirrada. Durante a especificação, vale a pena destacar alguns pontos:

Finalidade de Uso – Estação de trabalho, servidor ou sistema móvel como tablets e celulares. Cada dispositivo desse pode apresentar uma métrica diferente no licenciamento e nos valores (especialmente quando se fala de servidores).

Sistema Operacional – Há a necessidade de prover cobertura para todos os sistemas operacionais existentes na unidade, inclusive os mais antigos; e esse é um ponto problemático, pois sabemos que temos estações de trabalho mais antigas, com pouca memória, em que um antivírus mais pesado poderia inviabilizar sua atividade.

Fluxo de instalação – Diversos antivírus hoje possuem um mecanismo de instalação automatizado e silencioso. Na automatização, é capaz de instalar em máquinas de um departamento inteiro de uma única vez; e em outras situações, o modo silencioso faz com que o usuário nem perceba que está sendo instalado na sua estação de trabalho.

Administração do ambiente – Temos que lembrar sempre que administrar um parque de equipamentos é muito mais complexo que administrar nossa própria estação de trabalho, logo, é fundamental um console de administração que permita que sejam vistos todos os recursos ativos (equipamentos) e sua situação quanto à atualização. Outro ponto importante na administração é impedir que o usuário final consiga remover o antivírus da estação de trabalho; deve haver política onde somente o administrador qualificado do ambiente possa fazer esse tipo de atividade.

Atualização Centralizada – Imagina aquele cenário em que o seu antivírus avisa a todas as estações de trabalho para saírem da internet, buscando uma nova versão da definição de vírus em um mesmo momento do dia? O resultado seria catastrófico para sua conexão de saída com a internet, e é por essa razão que um processo de atualização centralizada é tão importante. Nesse modelo, apenas uma máquina central traz toda a atualização do antivírus para sua rede local e, posteriormente, é distribuída via rede local para as estações de trabalho.

Antivírus Gratuito – Muito cuidado com esse item, pois existem diversos antivírus de uso gratuito no mercado, mas a grande maioria deles deixa explícito que a versão gratuita é para uso em computadores pessoais, e não corporativos. O uso desses produtos de forma inadequada pode acarretar multas severas.

Banco de Dados

Esse tipo de software, quando comercial, quase sempre é dominado por duas empresas, o que gera um cenário em que ou se escolhe nominalmente qual a solução a ser adotada, ou se faz um grande teste ou PoC (Proof of Concept) e validar inicialmente qual sua melhor aderência a determinado fornecedor. Essa escolha é determinante, pois esse tipo de software tem sua substituição tão complexa que, por vezes, vê-se acontecendo renovações desse tipo de software, insatisfeito com o serviço prestado ou produto apresentado e sem capacidade efetiva de substituição.

O banco de dados raramente é o item final de uma compra. Normalmente, ele é decorrente de um produto comprado que precisa ser ampliado, e, nesse caso, há jurisprudência que suporte a especificação nominal do produto, pois, independentemente de qual seja, existem diversas empresas fornecedoras para esses produtos e há previsibilidade de concorrência.

São pontos de destaque no momento da seleção:

Edição do Banco de Dados – É bem comum que esse tipo de produto, dentro de uma mesma versão, ganhe edições com capacidades diferenciadas, normalmente conhecidas como “Standard” e “Enterprise”, podendo haver várias outras. Tem-se por trás disso uma série de diferenças de recursos específicos, logo, se a licitação for feita por produto nomeado, há a necessidade de especificar de forma totalmente inequívoca a edição ou de apontar detalhadamente quais os recursos são importantes, sempre considerando que a segunda hipótese abre um risco grande uma vez que os fornecedores podem fazer movimentações de recursos para melhor atender a um determinado processo de compra.

Modelo de Licenciamento – O modelo de licenciamento de banco de dados normalmente está amarrado à capacidade computacional a que se deseja atender. Nesse caso, a métrica mais estabelecida é a quantidade de núcleos dos processadores que será atendida. Há sempre uma questão importante que é a existência de núcleos físicos e núcleos lógicos. É aí que tudo pode se complicar. Para não correr risco, verifique a métrica que o fornecedor utiliza e dimensione em função do equipamento que será alvo de utilização. Verifique se há diferença do modelo de licenciamento caso esse banco de dados for ser executado em plataformas virtuais, pois há a possiblidade de uma contagem diferenciada ou produto diferenciado para plataformas virtualizadas.

Suporte a Virtualização – Virtualização e banco de dados são normalmente alvos de utilização antagônicas, contudo, atualmente, é, sim, uma estratégia manter ambientes virtuais e com bancos de dados em execução sobre eles. O destaque aqui fica por conta do suporte do fabricante a ambientes virtualizados, já que existem fornecedores que exigem que a virtualização ocorra em plataforma específica do fabricante.

O Acórdão do TCU 2.569/2018

O Tribunal de Contas da União (TCU) fez uma auditoria sobre as práticas comerciais dos grandes fornecedores de software ao governo federal e concluiu que os órgãos públicos contam com muito menos informações do que deveriam, o que traz sérios riscos de danos ao Erário. Em especial, o TCU indica que há pouca preparação para compras no modelo de computação em nuvem, ainda que o mercado aponte ser a tendência natural de contratação.

“A principal conclusão a que chegou este trabalho é que existe uma situação de hipossuficiência da Administração Pública Federal em relação aos grandes fabricantes de software. Há pouca ou nenhuma margem de negociação da APF ante a esses fornecedores, o que impõe a adaptação da contratação pública aos modelos de negócio privados, que são díspares entre as soluções similares, bem como modificam-se em ritmo acelerado”, indica o relatório que sustenta o Acórdão 2.569/18.

Diante das complexidades identificadas, o TCU faz uma série de recomendações aos órgãos públicos, a começar pela defesa de que prevaleçam as compras conjuntas, nas quais são agregadas as demandas de diversos órgãos. Contudo, uma das medidas que atingem em cheio o modelo de comercialização atual é a determinação da Corte de Contas para que seja proibido o pagamento à vista de licenças de software.

Assim, entre as medidas está determinar aos órgãos públicos que “adquiram o quantitativo de licenças estritamente necessário, vedando-se o pagamento antecipado por licenças de software e vinculando o pagamento dos serviços agregados às licenças efetivamente utilizadas, principalmente em projetos considerados de alto risco ou de longo prazo, nos quais o quantitativo deve ser atrelado à evolução do empreendimento, e devidamente documentado nos estudos técnicos preliminares”.

O relator, Aroldo Cedraz, diz que esse pagamento à vista é a metodologia corrente e defendida por ser a forma internacionalmente praticada pelo mercado. “Não socorre esse raciocínio 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ção pátria”, sustentou no voto, acompanhado pelos demais ministros.

A série de determinações e recomendações compõem o Acórdão 2569/18 e são fruto da auditoria que analisou compras de software e serviços realizadas entre janeiro de 2012 e novembro de 2016, período em que foram identificadas aquisições de pelo menos R$ 2,8 bilhões junto a meia dúzia de desenvolvedores, sendo um terço delas somente com a Microsoft – e 85% concentradas na própria Microsoft, IBM e Oracle.

Acesse a integra do acórdão do TCU pode ser encontrada, em que se pode extrair o texto completo da matéria. Cabe destacar que como se trata de um acórdão extremamente novo, de novembro de 2018, ainda não puderam ser dimensionadas todas suas possíveis repercussões.

Software Personalizado

O desenvolvimento de software personalizado para os governos é, sem sombra de dúvida, um dos grandes desafios que qualquer gestor de TICS da área pública encontra pela frente. Quando falamos de software personalizado, estamos falando daquele produto que é feito sob medida para atender às demandas específicas de uma secretaria ou unidade de negócios, sendo que esse desenvolvimento não é incomum, devido a sérias particularidades que são encontradas apenas nos serviços públicos e pelo fato de que poucas empresas de desenvolvimento de software se veem atraídas a desenvolver soluções de prateleira para atender a essa demanda.

Tenha em mente que esse tipo de desenvolvimento sempre será o resultado dos esforços do contratado para prestar o serviço de desenvolvimento com a área final que tem a necessidade de automatizar algum processo. É o time de tecnologia local que tem a tarefa de especificar e gerir as entregas. Por vezes, na equipe interna, não há disponibilidade de agente de especificação, e essa atividade acaba sendo remetida a um prestador de serviço externo. Essa situação grave poderá ter um crescente no risco da qualidade do produto entregue.

A mecânica do desenvolvimento de software personalizado por si só já requer um grau de conhecimento alto nas disciplinas da ciência da computação que abordam o tema. Quando falamos do desenvolvimento para o serviço público, toda uma nova linguagem de artefatos vem à tona, quando tornamos isso ainda mais específico colocando itens de saúde no meio, a chance de encontrar empresas que entendam do que está sendo dito é baixíssima.

Nessa perspectiva em que é muito difícil encontrar empresas que conheçam da sua demanda para que possam lhe apoiar no processo de desenvolvimento, a formação do profissional que exerce o papel de “analista de sistemas de saúde” é das competências mais importantes. Esse profissional será o responsável em apoiar as áreas da saúde que conhecem sua demanda e traduzir para uma linguagem mais neutra e amigável esperada pelos desenvolvedores.

O modelo de desenvolvimento atual quase sempre remete a passos como:

  1. Levantar a demanda com a área usuária do sistema a ser desenvolvido;
  2. Escrever essa rotina de forma neutra e amigável;
  3. Validar se essa escrita corresponde ao desejo da área fim;
  4. Levar a demanda à equipe de desenvolvimento;
  5. Receber da equipe de desenvolvimento o fragmento que foi desenvolvido;
  6. Validar se o que foi especificado foi entregue;
  7. Apresentar para a área fim o fragmento validando se o que foi solicitado ficou adequado à especificação.

Apesar de parecer um fluxo relativamente simples, diversos riscos devem ser percebidos aqui. Destaque para:

Além das etapas anteriores, há também a necessidade de atentar a detalhes técnicos de legislação, por exemplo, aqui vale citar a portaria específica de padrões de interoperabilidade de saúde (Portaria nº 2.073 de 2011) que estabelece diversos padrões para troca de informações em saúde; e além dessa, existem diversas adaptações que devem ser respeitadas como padrões de acessibilidade em uma página web, como a eMag, padrões de interoperabilidade de Governo Eletrônico ePING, layout web, identidade visual, entre outros, que devem ser detalhadas antes do desenvolvimento para que não haja retrabalho para se adaptar às normativas existentes.

Desenvolvimento Fechado

Esse tipo de processo licitatório é de grande risco, uma vez que ele compreende apresentar de uma vez só todos os requerimentos necessários para o desenvolvimento, dessa forma, a empresa contratada deverá apresentar uma proposta financeira para o desenvolvimento dessas fichas de requerimento, gerando, assim, o produto, que é o sistema de informação.

Essa situação pode ter riscos mitigados, fazendo com que as entregas sejam parciais e que a cada momento seja avaliada a qualidade do que está sendo entregue, tentando assim diminuir o impacto no final do processo.

Itens que não podem faltar em um processo de escopo fechado de desenvolvimento:

Fábrica de Software

A contratação de uma fábrica de software é uma estratégia muito utilizada quando se deseja desenvolver um software personalizado. Ela consiste na terceirização do desenvolvimento, como no caso do desenvolvimento fechado, mas difere no quesito do escopo, já que este foi definido previamente.

A utilização de fábrica de software requer uma organização importante uma vez que os componentes que vão fazer o desenvolvimento do software não têm conhecimento do todo, apenas da parte que está sendo enviada para cada um. Dessa forma, a qualidade da documentação é fundamental para que o produto de retorno seja adequado.

O uso de fábrica de software é tido como um modelo bem aceito dentro dos governos, tanto que já houve várias normativas e portarias para regular seu uso, porém, sempre há um ponto de impasse – qual a métrica a ser utilizada para a contratação?

No governo federal, a Secretaria de Tecnologia da Informação, órgão do Ministério do Planejamento, lançou a Portaria nº 4, de 2017, que estabelece o seguinte:

CAPÍTULO I

DAS DISPOSIÇÕES GERAIS

Art. 1º Nas contratações de serviços de desenvolvimento, manutenção e sustentação de software devem ser definidas métricas objetivas que permitam a gestão contratual, a mensuração e a devida remuneração dos serviços e produtos efetivamente entregues pela empresa contratada no contexto do processo de desenvolvimento de software adotado pelo órgão ou entidade.

Art. 2º Quando o órgão ou entidade optar por adotar métrica específica para mensuração de software em suas contratações, devem ser referenciados os normativos e manuais técnicos que definem as regras de uso e o cálculo da métrica de software escolhida, bem como o escopo da sua aplicação.

Ainda na mesma portaria é dito:

CAPÍTULO II

DA UTILIZAÇÃO DE MÉTRICAS EM SERVIÇOS DE DESENVOLVIMENTO DE SOFTWARE

Art. 5º Entende-se como serviço de desenvolvimento de software o conjunto de atividades a serem executadas com a finalidade de atender às necessidades do órgão ou entidade por meio da implementação de um novo software ou de uma nova funcionalidade, em conformidade com a metodologia de desenvolvimento por ele estabelecida e aplicados os procedimentos necessários à garantia da qualidade para desenvolvimento.

Essa portaria revoga determinação anterior em que a única métrica aceitável, pelo governo federal, é a métrica de ponto de função (PF). De fato, a métrica PF tem sido muito utilizada como unidade monetária (R$/PF) nos contratos de desenvolvimento e manutenção de sistemas pelas organizações governamentais brasileiras. Esse tipo de contrato permite o melhor balanceamento de riscos entre contratante e contratada, sendo recomendado pela Instrução Normativa – IN04 e pelos Órgãos de Controle do Governo Brasileiro.

Ponto de Função

A métrica Pontos de Função – PF foi criada por Allan Albrecht, em 1979, visando minimizar as dificuldades associadas ao uso da métrica Linhas de Código (LOC) como unidade de medida de tamanho de software, bem como suportar a previsão do esforço de desenvolvimento do projeto de software. Em 1986, uma Pesquisa do Quality Assurance Institute mostrou que PF é a melhor métrica para o estabelecimento de medições de qualidade e produtividade de projetos de software. Em 1993, PF se tornou a métrica mais utilizada e estudada na Engenharia de Software. Atualmente, a métrica de PF continua sendo a mais utilizada na indústria de software como métrica padrão na definição de indicadores, como insumo para derivação de estimativas de prazo, custo e esforço e no estabelecimento de contratos de software. Esta seção tem como propósito apresentar uma visão geral da contagem de PF, baseando-se nas regras de contagem do Counting Practices Manual (CPM) 4.3 (INTERNATIONAL FUNCTION POINT USERS GROUP, 2009).

Os principais objetivos da análise de PF são os seguintes:

A contagem de PF não ajustados consiste no mapeamento dos requisitos funcionais do projeto de software nos cinco tipos funcionais da Análise de Pontos de Função: Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE), Saída Externa (SE), conforme ilustrado na Figura 1.

 

 

O ALI – Arquivo Lógico Interno é um grupo lógico de dados, mantido dentro da fronteira da aplicação, por meio de um ou mais processos elementares. O AIE – Arquivo de Interface Externa é um grupo lógico de dados, referenciado por um ou mais processos elementares da aplicação; contudo, eles são mantidos dentro da fronteira de outra aplicação. Uma EE – Entrada Externa é um processo elementar que processa dados ou informação de controle que vem de fora da fronteira da aplicação. O seu objetivo principal é manter um ou mais ALI ou alterar o comportamento da aplicação. Uma Saída Externa é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. O seu objetivo principal é apresentar informações para o usuário por meio de um processamento lógico que deve conter: cálculos ou criar dados derivados ou manter ALI ou alterar o comportamento da aplicação. Uma Consulta Externa é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação. O seu objetivo principal é apresentar informação para o usuário por meio apenas de uma recuperação de dados ou informação de controle de um ALI ou AIE.

Cada função identificada possui uma complexidade associada: Simples, Média ou Complexa e uma contribuição para a contagem de Pontos de Função Não Ajustados, baseada na sua complexidade (Tabela 1). A determinação da complexidade e da contribuição funcional não é subjetiva, sendo baseada nas regras de contagem do CPM (INTERNATIONAL FUNCTION POINT USERS GROUP, 2009).

Tabela 1: Contribuição Funcional dos Tipos de Função [IFPUG, 2009]

 

 

A utilização do procedimento de contagem de Pontos de Função – PF, descrito no CPM [IFPUG, 2009], implica na existência do projeto lógico da aplicação. Nas fases iniciais do processo de desenvolvimento de software, os PF não podem ser medidos, e, sim, estimados. Sugere-se a utilização do método Contagem Estimativa de Pontos de Função (CEPF) nas estimativas de tamanho dos projetos de software para o estabelecimento de contratos ou elaboração de Editais.

O Tribunal de Contas do Estado de São Paulo emitiu o seguinte parecer para uso geral:

Metodologias para contratação de desenvolvimento, manutenção, correção e melhoria de software na Administração Pública

…

É importante observar que o objetivo da medição em Pontos de Função não é o de medir diretamente esforço, produtividade ou custo. Mas em conjunto com outras variáveis – como a tecnologia utilizada, capacitação e conhecimento da equipe, metodologia de desenvolvimento, etc. – a quantidade de Pontos de Função medidos poderá ser usada para derivar produtividade, estimar esforço e custo do projeto de software. Além disso, o acompanhamento do desenvolvimento de software poderá ser realizado utilizando-se os Pontos de Função – por exemplo, verificando se as funcionalidades (mais precisamente, tamanho funcional em pontos de função) estão sendo entregues no prazo.

A adoção da Análise de Pontos por Função – APF, além de substituir as estimativas feitas atualmente, tende também a substituir os modelos de contratação por homem/hora ou por postos de trabalho. Por isso, inicialmente é esperada a resistência de várias partes acostumadas a estes formatos de contratação.

Tudo que inova incomoda a quem está na zona de conforto. A informática é assim, sempre ligada na “velocidade dos bits”!

Vale ressaltar que a adoção da APF é um caminho a ser consolidado na Administração Pública paulista, pois se trata de uma medida de tamanho funcional para projetos de desenvolvimento e de melhoria (manutenção evolutiva) de software.

A APF permite a medição objetiva de serviços de desenvolvimento de soluções de software, por isso a adoção dessa medida é uma boa prática na contratação de serviços e está aderente ao Princípio da Eficiência.

Homem-Hora

Este modelo é aquele que se caracteriza pela alocação de profissionais terceirizados no desenvolvimento de aplicações. O conceito Homem-Hora  -HH pode ser aplicado a outras modalidades que não somente o desenvolvimento de software, contudo, ele vem sendo criticado pelos gestores que o contratam por ter uma remuneração desvinculada dos resultados, gerando assim um paradoxo que pode ser difícil de administrar, que é o que diz que quanto mais improdutivo eu sou mais eu recebo por isso.

Outro aspecto que também se destaca na contratação HH é que o escopo não precisa estar totalmente definido para trabalhar. Se por um lado isso pode ser visto como ponto a favor pela flexibilidade aceita a mudanças do escopo do projeto; por outro lado, também sinaliza que há evidentes problemas no processo de levantamento de dados.

A modalidade de contratação de HH foi duramente criticada no governo federal, sendo que a IN04 chegou a proibir esse tipo de contratação para o desenvolvimento de software. Hoje esse modelo de contratação é permitido, mas ainda há muitas ressalvas na sua utilização que, por várias vezes, pode ser vista como uma forma de terceirização do próprio departamento de TICS dos órgãos.

São os principais itens a se destacar no processo de contratação no modelo HH:

Uma das possibilidades em uma contratação seguindo o modelo HH é 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és de ter um valor para cada perfil de profissional, terá um grande montante de horas que podem ser distribuídas da melhor forma para o projeto.

A contratação de projetos de softwares personalizados por HH, quando passível de análise pelo TCU, pode esbarrar em uma determinação estipulada pela Súmula Vinculante N 269:

SÚMULA Nº 269

Nas contratações para a prestação de serviços de tecnologia da informação, a remuneração deve estar vinculada a resultados ou ao atendimento de níveis de serviço, admitindo-se o pagamento por hora trabalhada ou por posto de serviço somente quando as características do objeto não o permitirem, hipótese em que a excepcionalidade deve estar prévia e adequadamente justificada nos respectivos processos administrativos.

Requisito de Software

Independentemente do modelo de contratação, seja por hora-homem, seja por ponto de função, a elaboração do documento de requisito de software é fundamental para que o projeto de desenvolvimento seja bem-sucedido.

A elaboração dos requisitos de software sempre deve vir precedido do conjunto de software que faça a manutenção básica desse programa de computador – entenda por manutenção básica a capacidade de criar usuários, capacidade de criar grupos com regras de acesso e estipular as regras de acesso a determinados grupos de usuários. Quanto mais rica for essa etapa, mais segura e detalhada será sua capacidade de gerir os usuários. Um fato sempre importante de avaliar nas regras gerais é a capacidade de visualizar e editar cada informação. Quanto mais fragmentada for a necessidade de visualização/edição de cada informação no sistema de informação, mais importante é a capacidade que deverá existir nesse conjunto básico. Um exemplo hipotético, imagine um sistema de informação no qual haverá uma tela de cadastramento de pessoas. Nessa tela, constam algumas informações importantes e sensíveis como, por exemplo, o medicamento que ela está tomando. Imagine agora que essa informação referente a medicamento deverá estar disponível apenas à equipe clínica, é fundamental que a parte básica do sistema seja capaz de identificar essa situação e conseguir dar acesso à parte dos medicamentos apenas aos profissionais que façam parte do grupo que deve ter acesso.

A estrutura básica de um processo de requisito de software faz parte da Engenharia de Software e pode ser dividida seguindo o seguinte esquema:

 

 

Para começar a falar sobre requisitos funcionais e não funcionais, precisamos entender o que são requisitos. Eles são solicitações, desejos, necessidades. Um requisito é a propriedade que um software exibe para solucionar problemas reais, é a conjuntura indispensável para satisfazer um objeto.

Quando se trata de um software sob demanda, por exemplo, um requisito é uma maneira pela qual o sistema oferecido deve fazer, ou um condicionamento no desenvolvimento do sistema. Lembrando que, em ambas as ações, embora o programador ou o arquiteto de software tenha suas opiniões, é importante chegar em um acordo para resolver o problema do cliente. Esse sempre será o foco.

É muito importante frisar que manter uma concordância com os clientes e com aqueles envoltos é um dos principais objetivos dos requisitos.

Um dos principais responsáveis pelo sucesso dos softwares, os requisitos, são a base para estimativas, modelagem, projeto, execução, testes e até mesmo para a sua manutenção.

Assim, os requisitos estão presentes ao longo de todo o ciclo de vida de um software.

Ao começar um projeto, os requisitos já devem ser levantados, entendidos e documentados. Assim como realizar atividades de controle de qualidade para verificar, validar e garantir a qualidade deles.

Gerenciar a evolução dos requisitos é importante, estando cientes de que os negócios com sua dinâmica não garantem estabilidade e podem vir a sofrer alterações. Desse modo, é necessário manter a rastreabilidade entre os requisitos e as outras peças do projeto.

Requisito Funcional

Esclarecido o que são requisitos, é hora de desmembrá-los explicando cada um. Começaremos, portanto, pelos requisitos funcionais.

Dentro da engenharia de softwares, podemos destacar o requisito funcional, em que há a materialização de uma necessidade ou solicitação realizada por um software. Porém, vários requisitos funcionais podem ser realizados dentro de uma mesma funcionalidade.

São variadas as funções e os serviços que um sistema pode fornecer ao seu cliente. Descrevemos abaixo algumas das inúmeras funções que os softwares podem executar:

Os requisitos funcionais são de extrema importância no desenvolvimento de aplicativos, pois, sem eles, não há funcionalidades nos sistemas.

Seus modelos devem ser construídos em um nível de entendimento claro e objetivo, além de um código-fonte totalmente aplicável. Conclusão: para obter requisitos funcionais de qualidade, a fábrica de software deve estar atenta à síntese e à semântica deles.

Requisito não Funcional

Uma vez que os requisitos funcionais definem o que o sistema fará, a Engenharia de Software afirma que os requisitos não funcionais definem como o sistema fará, embora não seja tão clara assim essa definição.

Os Requisitos não Funcionais não estão relacionados diretamente com as funcionalidades de um sistema. Também chamados de atributos de qualidade, ainda assim são de grande importância no desenvolvimento do sistema.

Tratados geralmente como premissas e restrições técnicas de um projeto, os requisitos não funcionais são praticamente todas as necessidades que não podem ser atendidas por meio de funcionalidades.

Geralmente mensuráveis, os requisitos não funcionais definem características e impõem limites do sistema, como método de desenvolvimento, tempo, espaço, sistema operacional, dentre outros, cuja medida pode ser determinada. É importante que se associe essa medida ou referência à cada requisito não funcional.

Para ficar mais claro, temos alguns exemplos de propriedades e suas métricas:

Esses são apenas alguns dos exemplos em que as propriedades e métricas são associadas a cada requisito não funcional.

Além do mais, esses requisitos não funcionais são divididos em três tipos principais: Requisitos de Produto Final; Requisitos Organizacionais; Requisitos Externos, que se dividem em diversos outros tipos.

Listamos abaixo alguns exemplos básicos de requisitos não funcionais:

Muitos softwares não obtêm sucesso e chegam a fracassar. Isso se dá devido a não definição prévia desses atributos de qualidade na priorização ao definir uma arquitetura.

Se esses requisitos não funcionais levantam aspectos tão importantes nos sistemas de softwares e se desconsiderá-los é submeter-se a uma futura falta de êxito ou deficiência no desenvolvimento do software, qual o motivo de tanto descaso?

Apenas as grandes empresas, nas quais existem uma equipe de TI com maior disposição, em que acompanham de perto a elaboração dos softwares, é que dão credibilidade aos requisitos não funcionais.

Eles são de difícil estimativa tanto para prazo quanto trabalho ou custo.

É grande o número de fornecedores que julgam “gastar mais” no desenvolvimento de app, por exemplo, ao lidarem com os requisitos não funcionais e só não os ignoram quando são solicitados explicitamente pelo cliente.

De certo modo, todas as atividades que são relacionadas com os requisitos fazem parte do processo de “engenharia de requisitos”.

Uma das áreas essenciais no desenvolvimento de softwares, a engenharia de requisitos possui algumas definições segundo a literatura técnica da engenharia:

Regra de Negócio

Diferença de “requisito funcional” e “regra de negócio” é algo comum na cabeça de vários analistas de sistemas.

Eu imagino que antes do lançamento do microcomputador, o termo “regra de negócio” era algo interpretado totalmente isolado dos softwares empresariais, ou talvez nem fosse um termo conhecido pelas pessoas. Nos tempos atuais, é difícil encontrar alguém que entenda regra de negócio como algo isolado do software.

Quando se fala “regra de negócio”, praticamente sempre é no contexto de um sistema.

Estes dois conceitos (requisito funcional e regra de negócio) se encontram (se cruzam) a toda hora na modelagem de um sistema, mas são coisas diferentes.

É possível uma empresa mais arcaica viver sem software, mas mesmo essa empresa não consegue viver sem regras de negócio.

As regras de negócio são restrições/premissas necessárias para o negócio “acontecer”. Poderíamos elencar dezenas de regras de negócio, mas é fundamental que seja claro que regras de negócio existe sem sistema, e que uma empresa não existe sem regras de negócio.

Diferença entre Requisito Funcional e Regra de Negócio

 

A diferença entre requisito funcional e regra de negócio, conceitualmente falando, é que o requisito funcional se refere a “o que o sistema deverá fazer”, enquanto a regra de negócio refere-se a “como o sistema deverá fazer”. Do ponto de vista do negócio (negócio do cliente para o qual o sistema está sendo feito), ambos são necessidades (requisito funcional e regra de negócio), mas cada uma com um foco diferente.

Uma boa dica para saber o que é regra de negócio é perceber quando há condições: “somente, quando, requer, se, obrigatório, sempre”. Requisitos não possuem condições, regras “são” condições. Requisitos são ações objetivas, desejo, solicitação.

Atributos de uma boa Regra de Negócio

 

Uma regra de negócio com qualidade precisa atender a alguns atributos específicos. Na literatura, tanto nacional quanto estrangeira, não há material que especifique esses atributos.

Entretanto, devido à estrutura sintática de uma regra de negócio ser muito semelhante à de um requisito funcional, elencamos alguns atributos (alguns comuns aos requisitos funcionais) a serem considerados na especificação de uma regra de negócio.

A seguir a lista dos atributos que considero relevantes.

Atributo Referente a
Unidade A regra de negócio deve propor/viabilizar uma única coisa apenas. Não deve atender a mais de uma restrição. A regra de negócio “cálculo de salário” não é unitária, pois se refere implicitamente ao cálculo de qualquer tipo de salário; e, em qualquer empresa, existem formas diferentes de calcular salário (para profissional ativo, aposentado, estagiário, efetivo, licenciado etc.). Esta regra de negócio assume assim várias responsabilidades, quando deveria assumir apenas uma.
Completude A regra de negócio deve ser autocontida, deve ter “início/meio/fim”, ser completa. A regra de negócio “cálculo de salário” não é completa, só conta “parte da estória”. Para ser completa, deveria ser algo como “cálculo de salário para profissionais afastados há mais de 15 dias”.
Consistência Não deve contradizer outra regra de negócio do mesmo escopo do projeto. É como termos duas regras de negócios se propondo a fazer uma mesma coisa, mas cada regra de negócio se propondo a fazer essa coisa de formas diferentes.
Atomicidade Uma regra de negócio para ser atômica precisa também ter unidade, pois atomicidade remete a assumir apenas uma responsabilidade. No entanto, também, deve ser indivisível, não podendo ser decomposta. Muitas regras de negócios possuem conjunção, dependem de outras para se realizar. Onde temos duas regras de negócios, como: “calcular juros para pagamento atrasado” e “incluir juros para pagamentos de financiamento imobiliário atrasados”, na realidade, se pensarmos em atomicidade, temos uma única regra de negócio que é “calcular juros para pagamentos atrasados de financiamento imobiliário”.
Não Ambiguidade Não pode ser ambígua, definir algo que não fica claro o que é. A regra de negócio “critérios para processamento de faturas” é ambígua. Fatura de quê? Critérios para processar o quê? “Critérios para processamento de fatura de mensalidade” já é melhor, mas ainda é ruim. Mensalidade de quê? Seria não ambíguo se não deixasse dúvidas, algo como “critérios para processamento de faturas de mensalidades de alunos do segundo grau” ou “critérios para processamento de faturas de mensalidades de qualquer aluno impendente de série”.
Verificável Não adianta ter uma regra de negócio se ela não é palpável, possível de associar com um requisito funcional que será construído, testado etc. Uma regra de negócio tem que ser testável, tem que ser possível atestar que ela foi atendida por meio de algum requisito funcional. Para isso, tem que ser também rastreável.
Rastreável Deve ser possível achar a regra de negócio no sistema pronto. Como saber se uma regra de negócio foi atendida? Para isso, é necessário ter rastreabilidade, e isso só é possível ligando as pontas (associar a regra de negócio ao requisito funcional, associar o requisito funcional à interface gráfica, que será associada a um caso de uso, que será associado a funcionalidades, que serão implementadas etc.).
Exemplificável Muitas regras de negócios tratam de cálculos, fórmulas, algoritmos etc. Uma regra de negócio deve poder ser exemplificada fora do contexto do sistema, para assim facilitar o entendimento de seu escopo pelos profissionais que a implementarão/validarão.

Um detalhe importante é que uma regra de negócio não possui prioridade. Como uma regra de negócio, no contexto de um sistema, somente existe se associada a um ou a mais requisitos funcionais, a prioridade aplicada à regra de negócio será a prioridade aplicada ao requisito que depende dela.

Estrutura de uma Regra de Negócio

Não há um padrão estabelecido sobre a estrutura de uma regra de negócio. Contudo, a maioria utiliza um formato semelhante, contendo campos específicos. O modelo a seguir contempla os campos mais relevantes, com posterior descrição de cada um.

Identificador
Nome
Módulo
Data de criação Autor
Data da alteração Autor
Versão Dependências
Descrição

 

Explicando cada campo

Campo Descrição
Identificador Sufixo seguido de um identificador único. O sufixo geralmente utilizado é regra de negócio (regra de negócio), e o identificador único geralmente é composto de quatro dígitos (podendo ser mais, conforme a o tamanho do sistema que está sendo especificado).
Nome Nome curto da regra de negócio, mas que possibilite entender bem o que regra de negócio faz apenas pelo nome.
Módulo Módulo ao qual o requisito funcional pertence. Se for um sistema pequeno que não possua nenhum módulo, somente o próprio sistema, deve ser preenchido com N/A (não se aplica).
Data de criação Data da criação da regra de negócio, ou a data em que ela foi especificada.
Autor Profissional que especificou a regra de negócio pela primeira vez, quem a criou.
Data da última alteração Data em que houve a última alteração na regra de negócio.
Autor Profissional que alterou a especificação da regra de negócio pela última vez.
Versão Número da versão da regra de negócio. Geralmente utiliza-se algo simples, como 1, 2 etc. A versão inicial sempre é a 1, e a cada alteração, incrementa-se a versão (na criação versão 1, na primeira alteração versão 2 etc.).
Dependências Quais requisitos funcionais são dependentes da regra de negócio para serem realizados. Coloca-se apenas o identificador dos requisitos funcionais.
Descrição Descrição detalhada (a mais detalhada possível) da regra de negócio.

 

Exemplo de uma Regra de Negócio especificada

Identificador RN0101
Nome Validação da identificação da pessoa que solicita a retirada/entrega do material
Módulo Gestão de Armazéns
Data de criação 01/04/2018 Autor Paulo
Data da alteração N/A Autor N/A
Versão 1.0 Dependências RN0099
Descrição Sempre que uma pessoa se dirigir ao departamento de expedição para solicitar uma mercadoria, ela deve se identificar com seu documento de identidade. O profissional do departamento de expedição deve certificar-se que o documento é válido.

Para validar o documento fornecido pelo solicitante, o seu número deverá ser validado no sistema da Secretaria de Segurança Pública do Estado de São Paulo, por meio de funcionalidade correspondente no módulo de controle de expedição. Se o documento não tiver como órgão emissor SSP-SP, não precisará ser validado, mas deverá ser microfilmado e ter uma cópia armazenada no sistema, por meio de funcionalidade específica.

 

Software Livre

As duas principais organizações internacionais responsáveis pela proteção e promoção do software livre, a Free Software Foundation (FSF)e a Open Source Initiative (OSI), atuam também 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ários:

  1. A liberdade de executar o programa, para qualquer propósito;
  2. A liberdade de estudar o programa, e adaptá-lo para as suas necessidades;
  3. A liberdade de redistribuir cópias do programa de modo que você possa ajudar ao seu próximo;
  4. A liberdade de modificar (aperfeiçoar) o programa e distribuir estas modificações, de modo que toda a comunidade se beneficie.

Lembrando que o acesso ao código-fonte é um pré-requisito para as liberdades 1 e 3, uma vez que não é possível estudar ou adaptar o programa sem acessar o código-fonte.

Para que as quatro liberdades sejam satisfeitas, é necessário que o programa seja distribuído com o seu código-fonte e que não sejam colocadas restrições para que os usuários alterem e redistribuam esse código. Segundo a Free Software Foundation, é comum que a comunidade de usuários confunda softwares gratuitos (freewares) com softwares livres. No entanto, a fundação enfatiza que há um grande equívoco nisso e que usuários devem entender que um software livre – ao contrário de um software gratuito – é aquele que respeita a liberdade e o senso de comunidade dos usuários. Dessa forma, um software livre tem como marcante a característica de dar ao usuário a liberdade de copiar, distribuir, modificar e estudar o programa sem pagar ou pedir permissão ao autor. Para garantir essas liberdades, o software livre garante aos seus usuários acesso a seu código-fonte. Diferentemente disso, um software gratuito é apenas um programa gratuitamente copiado e distribuído em sua forma executável, não podendo ser modificado ou estudado dada a ausência do fornecimento do código-fonte. . Isso significa que um desenvolvedor que distribuir um software livre pode cobrar por isso ou fornecer o software de maneira gratuita.

Relato de experiência:

Segundo André Luiz de Almeida, ex-diretor de Tecnologia da Informação da Secretaria de Saúde de São Paulo:

“Durante anos à frente de um departamento de tecnologia da informação, diversos processos de aquisição foram encabeçados, dos mais diversos tipos, e com o tempo, veio a experiência, e relatarei agora as principais lições aprendidas:

Software de Prateleira

A aquisição 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ção do TCU que proíbe o modelo anterior, todo o processo de aquisição está passando por adaptações. Essas adaptações são extremamente válidas, basta consultar o documento da TCU (Acórdão 2.569/2018) os valores que essas empresas receberam dos órgãos públicos. Na sua essência, o que muda é que não é mais permitido pagar por licenças que não estão em uso, coisa que era feito quase que como praxe no processo de aquisição. Sempre se dimensiona o parque com algum crescimento e essas licenças de uso eram adquiridas e pagas e as vezes ficavam fora de utilização por muito tempo.

Vale observar que a escolha de um software é sempre um processo muito delicado, especialmente se esse software for destinado para as estações de trabalho. Imagine num cenário hipotético a instalação de um antivírus, instalar em um computador é uma tarefa relativamente simples e tranquila, agora imagine fazer isso em uma rede de mais de 10.000 computadores? Qual a logística para isso? Como conseguir atacar todas as estações? Essas são questões que impactam muito na operação, mas há diversos pontos além do fato da mudança na estação 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.

Pontos de maior atenção na escolha de um software são:

Continuidade – Garanta na documentação que o software receberá atualizações por um período adequado.

Adequação a sua plataforma – Deixe claro na documentação como é composto seu parque de computadores detalhando memória, sistema operacional, logística de instalação e requerimentos de acesso a instalação (imagine instalar um upgrade em computadores que estão em hospitais, há a necessidade de planejamento prévio).

Nível de suporte esperado – Em caso de problemas qual o canal a ser acessado e em quanto tempo haverá apoio na sua operação.

Requisitos não Funcionais

Essa definição é uma das partes mais negligenciadas no desenvolvimento de software quando feito por terceiros e as consequências desta negligência podem ser determinantes no sucesso do projeto. Imagine o cenário onde todo o software foi feito de forma que para ser executável há a necessidade do investimento de monta considerável para aquisição de um novo hardware ou que use um banco de dados que não é suportado por este órgão.

Esse conjunto de definições claramente computacionais passam por especificações técnicas que devem estar atentas a alterações de mercado, um exemplo de um problema recente foi a finalização dos sistemas operacionais de 32 bits para estações de trabalho. Vários sistemas criados em tempos anteriores não ficaram atentos a esse tipo de mudança e hoje pode haver estações de trabalho sem possibilidade de atualização pois há um aplicativo desenvolvido que só tem execução prevista em ambiente de 32 bits.

Regras de Negócio

Se existe alguma parte do desenvolvimento de software que menos se pareça com uma ciência exata é o levantamento das regras de negócio. Nessa etapa, é fundamental que o entrevistador tenha a perspicácia de conseguir entender os meandros pelo qual está caminhando. Não é incomum durante uma entrega haver uma discrepância entre o que foi solicitado e o que foi entregue. É exatamente essa etapa de entendimento das regras de negócios e requisitos funcionais que deve diminuir essa ocorrência. Uma das melhores práticas para se mitigar essa ocorrência é 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á totalmente expressa no documento de regra de negócio. Isto feito, ainda na tentativa de diminuir a discrepância entre o solicitado e o entregue é uma boa prática solicitar ao gerente ou responsável da área que destaque um outro revisor. Esta etapa tenta eliminar o viés de olhar único, tentando assim atender de forma mais global e não somente a um interlocutor.

Esse compartilhamento de responsabilidade na montagem das regras de negócio, sempre que possível, requer um passo final que é o compartilhamento e a publicidade do documento de requisito com o gerente/responsável pela área final, uma vez definido o requisito/regra, validado com outro usuário, é fundamental que copias assinadas sejam enviados ao responsável da área.”.

Resumo – Principais Pontos de Atenção

 

ANEXOS

Disponibilizamos a seguir alguns exemplos de editais e termos de referência que podem ser úteis: