Parte 1 – Comprar pronto, desenvolver internamente ou desenvolver externamente?
Parte 2 – Metodologia para compra de software
Parte 4 – Conclusão
Requisitos para compra de software
Muito bem, chegou a hora da equipe de TI assumir o seu papel e definir quais são os requisitos técnicos que serão avaliados no processo de escolha do software. Esta é uma tarefa bastante espinhosa pois são muitas variáveis a serem consideradas. O serviço público tem novamente uma dificuldade extra, uma vez que se levantar exigências obrigatórias muito altas, corre o risco de não encontrar nenhuma empresa que atenda às suas expectativas e então toda a licitação é cancelada. Por outro lado, se pontuar poucas coisas, as empresas com sistemas de baixa qualidade ganharão a licitação por apresentarem o menor preço.
Para facilitar este trabalho, você pode fazer primeiro um brain storm e colocar no papel todos os ítens técnicos que você gostaria de encontrar no software. Depois você deve filtrar aqueles que são pouco relevantes e verificar se existem soluções que atendam aos seus critérios. Por fim você deve definir em que posição cada critério deve estar:
- O – Requisito obrigatório: é aquele que quando não estiver presente desclassifica completamente uma proposta. Deve-se tomar um especial cuidado para não excluir de cara soluções que possam não atender um requisito específico e ainda sim ser uma opção viável.
- Requisito desejável: é aquele que não desclassfica uma proposta mas servirá para compor uma nota técnica final. Você pode atribuir pesos diferentes para cada ítem como:
- MD – Muito desejável (5 pontos),
- D – Desjável (3 pontos),
- PD – Pouco desejável (1 ponto).
- C – Requisito contratual: é aquele que compõe uma exigência contratual obrigatória que influenciará no custo global de implantação e manutenção. Os ítens se referem em geral a forma como os serviços da empresa contratada deverão ser realizados.
Vejamos aqui alguns requisitos que você poderá querer utilizar como ponto de partida para a sua pontuação. Longe de querer apontar uma forma acabada, a intenção aqui é demonstrar um exemplo de como comparar soluções de software, sobre o ponto de vista de TI. A classificação e escolhas dos ítens variam muito em cada caso. Dependem da maturidade do mercado de software para a solução que você deseja adquirir. Os pesos atribuídos para cada ítem são mais para efeito de ilustração e devem variar com a cultura de TI existente.
Documentação Fornecida
Aqui está em jogo a capacidade do software em fornecer informação em diversos níveis em com diferentes qualidades. A qualidade da documentação está diretamente relacionada com a capacidade de manutenção do software comprado. Quanto melhor a documentação, menor o custo de manutenção e menor o tempo necessário para correções de erro e implantação de novas funcionalidades.
| Ítem | C | O | MD | D | PD |
| Dicionário de Dados contendo descrição de tabelas, chaves estrangeiras, índices, visões, sequências, gatilhos, funções, procedimentos e roles | X | ||||
| Diagrama Entidade Relacionamento | X | ||||
| Diagramas de caso de uso (UML 1.1 ou superior) | X | ||||
| Diagramas com regras de negócio em outro formato | X | ||||
| Diagramas de classes (UML 1.1 ou superior) | X | ||||
| Outros diagramas UML 1.1 ou superiores | X | ||||
| Manual do usuário impresso | X | ||||
| Ajuda on-line para o usuário com opção de busca | X | ||||
| Ajuda on-line sensível ao contexto | X | ||||
| Controle de versão de toda a documentação | X | ||||
| Atualização de toda a documentação a cada nova versão do software | X | ||||
Vale aqui verificar qual é o formato em que as documentações técnicas estão disponíveis. É sempre interessante receber a documentação em formato impresso (alguns diagramas podem necessitar de papel de tamanho especial como A2 ou A1) e formato eletrônico. O formato eletrônico é mais adequado para receber quando houverem apenas pequenas alterações do software. No entanto, muitas empresas utilizam formatos que só abrem em programas específicos, dificultando a sua manipulação.
Tecnologia
Aqui a maioria das pessoas deve procurar se afastar dos modismos e procurar tecnologias já consagradas no mercado. Ferramentas proprietárias tem o azar de perderem o suporte depois de algum tempo, o que pode causar transtorno a longo prazo. Deve-se evitar ferramentas pouco robustas como geradores de código e RAD.
Um cuidado especial deve ser tomado com custos relacionados a tecnologias proprietárias. O custo das licenças deve ser contabilizado no custo total de implantação. O custo de manutenção destas ferramentas também deve ser contabilizado no custo total de manutenção. Particularmente, a maioria das linguagens de programação não exigem licenças de uso para executar a aplicação final, no entanto existem ferramentas que utilizam interpretadores que convertem o código da aplicação em código de máquina, necessitando de licenças por conexão ou por processador.
| Ítem | C | O | MD | D | PD |
| Uso de SGDB relacional multiplataforma compatível com a linguagem SQL | X | ||||
| Uso de protocolo de comunicação TCP/IP | X | ||||
| Uso de servidor de aplicação multiplataforma | X | ||||
| Interface com usuário multiplataforma | X | ||||
Se possível dê preferência (colocando como ítem desejável) por tecnologias que sua equipe já tem experiência, principalmente se houver a intenção de adquirir o código fonte do software. Uma atenção especial neste sentido deve ser dada às tecnologias de comunicação e de banco de dados. Você pode ser obrigado a fazer investimentos significativos de precisar suportar tecnologias novas nesta área.
Arquitetura
A arquitetura do software é uma área importante no mundo corporativo. Softwares cliente-servidor estão sendo aposentados por apresentarem difícil manutenção e baixa escalabilidade.
Desenvolvimento WEB
Este ítem está destacado aqui por apresentar uma série de especificidades que merecem atenção especial. As aplicações web tem inúmeras vantagens que fogem do escopo deste texto, no entanto, uma boa aplicação deve atender a alguns critérios mínimos que se esquecidos podem trazer surpresas desagradáveis para os usuários. As interfaces WEB tem se tornado muito populares, mas não são adequadas ainda quando você precisa de entrada de grande volume de dados ou quando precisa de ferramentas gráficas de edição avançadas. Se você não pretende utilizar aplicações WEB, você pode pular esta parte.
| Ítem | C | O | MD | D | PD |
| Homologação nos navegadores IE 6.0, Firefox 1.0 e Safari 1.0 e todas versões superiores | X | ||||
| Possuir CSS 1.0 válido | X | ||||
| Possuir HTML ou XHTML válido | X | ||||
| Utiliza servidor web multiplataforma | X | ||||
| É plenamente funcional sem Java instalado no cliente | X | ||||
| É plenamente funcional sem JavaScript habilitado | X | ||||
| Possui suporte a https | X | ||||
A parte mais importante aqui é garantir que a aplicação WEB seja escrita utilizando os padrões da W3C, garantindo que a aplicação funcione em diferentes situações.
Metodologia de desenvolvimento
A metodologia de desenvolvimento adotado está diretamente relacionada com o risco da empresa possuir métricas capazes de cumprir prazos e orçamentos. Uma metodologia formal bem documentada e aplicada deve trazer segurança o processo de desenvolvimento. Na área corporativa, a certificação CMM e CMMI são sinônimos de qualidade nesta área. No entanto, nem sempre se encontra fornecedores com este tipo de certificação para o tipo de software que se deseja adquirir. O processo de certificação CMMI custa atualmente cerca de U$ 400 mil, sendo assim, a SOFTEX criou uma iniciativa de certificação nacional chamada MPS.BR baseado no CMMI que está permitindo fábricas de software de menor porte alcançar uma certificação. O MPS.BR é ainda muito novo, mas estima-se que um número cada vez maior de pequenas e médias empresas adotem esta certificação no Brasil.
Deve-se ter em mente que quanto mais crítico e complexo for o software, mais importante será a contratação de uma empresa com certificação.
| Ítem | C | O | MD | D | PD |
| Certificação CMM ou CMMI nível 3 ou superior | X | ||||
| Certificação CMM ou CMMI nível 2 | X | ||||
| Certificação ISO 15504 nível 3 ou superior | X | ||||
| Certificação ISO 15504 nível 2 | X | ||||
| Certificação ISO 12207 | X | ||||
| Certificação MPS.BR níveis F e G | X | ||||
| Certificação MPS.BR níveis E ou superior | X | ||||
Caso você não encontre empresas certificadas que forneçam o software desejado, você terá que pensar na seguinte tarefa: como verificar se um fornecedor possui um modelo de desenvolvimento confiável onde seja visível as etapas clássicas do desenvolvimento de software (análise, especificação, projeto, implementação, teste, documentação, treinamento, implementação e manutenção). Segue alguns indicadores que podem ser utilizados.
| Ítem | C | O | MD | D | PD |
| Organograma detalhado da equipe de desenvolvimento | X | ||||
| Descrição detalhada das funções da equipe de desenvolvimento | X | ||||
| Modelo de Processo de Desenvolvimento de Software formalizado | X | ||||
| Utiliza RUP | X | ||||
| Utiliza controle de versão do código fonte | X | ||||
Possui equipes distintas para
| X | ||||
| Possui equipe distinta para gerência de projetos | X | ||||
| Realiza testes do tipo Caixa Branca | X | ||||
| Realiza testes do tipo Caixa Preta | X | ||||
| Realiza testes do tipo Caixa Cinza | X | ||||
| Realiza testes de unidade, integração e sistema | X |
Usabilidade
A usabilidade diz respeito a facilidade com que o usuário lida com a aplicação. Em geral, uma boa usabilidade garante maior produtividade e satisfação e menor ocorrencia de erros por parte do operador do software.
| Ítem | C | O | MD | D | PD |
| Interface e menssagens traduzidas para o Português do Brazil. | X | ||||
| Validação dos tipos dados inseridos | X | ||||
| Exibe falhas de validação após a digitação de cada campo | X | ||||
| Exibe apenas as funções ativas na tela | X | ||||
| Solicita confirmação do usuário para ações destrutivas ou não reversíveis | X | ||||
| Realiza paginação de listas | X | ||||
| Possibilita a inserção de texto com letras maiúsculas | X | ||||
| Possibilita plena navegação na aplicação sem uso do mouse | X | ||||
| Tabulação dos campos segue a órdem em que aparece na tela | X | ||||
| Possui busca fonética no Português do Brasil em campos de texto | X | ||||
| Exporta relatórios no formato CSV | X | ||||
| Exporta relatórios no formato PDF | X | ||||
| Exporta relatórios no formato MS Word 2000 ou superior | X | ||||
| Exporta relatórios no formato MS Excel 2000 ou superior | X | ||||
| Exporta relatórios no formato ODF | X | ||||
| Permite que o operador selecione um tema em alto contraste | X | ||||
| Permite que o operador aumente o tamanho da fonte padrão do texto | X | ||||
| Possui teclas de atalho para as principais funções e menus | X | ||||
| Sinalização gráfica informando o status de operações longas ou em várias etapas. | X | ||||
| Botões exibem dicas quando o ponteiro do mouse para sobre eles | X |
Interoperabilidade
Esta categoria diz respeito a capacidade do sistema de se integrar com os seus demais sitemas legados ou que possam vir a ser adquiridos futuramente. Suportar protocolos e padrões abertos são requisitos obrigatórios. A questão de interoperabilidade é tão importante que o Governo Federal criou o e-PING que é um documento trata com detalhes o assunto. A versão 1.0 do e-PING foi publicada em 2005 e continua sendo atualizada constantemente, se tornando uma referência obrigatória nesta área.
Segurança e Auditabilidade
Esta categoria de requisitos visa garantir a segurança e integridade das informações contidas no sistema bem como rastrear possíveis problemas ocorridos durante a operação do software.
| Ítem | C | O | MD | D | PD |
| Utiliza integridade referencial no banco de dados | X | ||||
| Utiliza controle de transações para operações concorrentes | X | ||||
| Não registra usuários da aplicação como usuários do banco de dados | X | ||||
| Armazena senhas de usuários em formato criptografado | X | ||||
| Registra histórico de operações realizadas pelos usuários | X | ||||
| Registra erros de importação de dados externos | |||||
| Registra erros da aplicação dentro do servidor | X | ||||
| Possui busca nos registros históricos por nome de usuário, data e tipo de operação | X | ||||
| Proteção contra injeção de SQL | X | ||||
| Criação de perfis de usuários | X | ||||
| Atribuição de usuários ou perfis de usuários a um perfil de usuário. | |||||
| Atribuição de permissões para cada funcionalidade por usuário | X | ||||
| Atribuição de permissões para cada funcionalidade por perfil de usuário | X | ||||
| Atribuição de permissão para cada usuário a uma faixa de valores em funcionalidades específicas | X | ||||
| Possibilidade de inativar usuários por período determinado | X | ||||
| Possibilidade de inativar usuários por período indeterminado | X | ||||
| Possibilidade de inativar grupos de usuários por período determinado | X | ||||
| Possibilidade de inativar usuário em data prédeterminada | X | ||||
| Expira seção do usuário após determinado de inatividade | X |
Implantação e Manutenção
Este ítem descreve como deve ser o processo de implantação e manutenção. Os prazos aqui definidos tem impacto direto nos custos de implantação e manutenção do Software.
| Ítem | C | O | MD | D | PD |
| Importação, checagem de consistência e remodelagem de dados já existentes para o novo software | X | ||||
| Análise de requisitos, adequação do software e testes | X | ||||
| Implantação de funcionalidades principais em até 6 meses após início da vigência do contrato | X | ||||
| Implantação de funcionalidades secundárias em até 12 meses após início de operação das funcionalidades principais | X | ||||
| Treinamento dos usuários do software antes da implantação do Software | X | ||||
| Treinamento da equipe de TI demonstrando o modelo de dados do Software | X | ||||
| Treinamento ou reciclagem de usuários anualmente após implantação do Software | X | ||||
| Criação de interfaces com outros softwares já existentes ou que venham a ser implantados em até 20 dias úteis | X | ||||
| Implantação ou alteração de funcionalidades por força de alteração na legislação federal, estadual ou municipal | X | ||||
| Correção de erros críticos em até 4 horas | X | ||||
| Correção de erros graves em até 24 horas | X | ||||
| Correção de demais erros em até 5 dias úteis | X |
Aqui, é possível que alguns fornecedores lhe digam que não tem condições de cumprir alguns prazos exigidos. Não deve-se descartar imediatamente estas empresas. Se o fornecedor adquiriu uma boa avaliação nos requisitos de metodologia de desenvolvimento, e possui uma equipe de desenvolvimento com um porte mediano em comparação aos demais fornecedores, é possível que seus prazos sejam realmente impraticáveis. É recomendável discutir esta questão com outros fornecedores e avaliar se os prazos são viáveis e se for o caso altera-los.
Equipe de desenvolvimento
Este grupo de requisitos visam medir a qualidade da equipe de desenvolvimento, bem como o porte da mesma. Uma grande equipe garante que a simples saída de um funcionário do fornecedor não vá comprometer o projeto como um todo além de permitir a alocação de mais recursos em épocas de grandes demandas.
| Ítem | C | O | MD | D | PD |
| 50 ou mais pessoas da equipe de desenvolvemento com jornada acima de 30 horas semanais em regime CLT | X | ||||
| 10 ou mais membros da equipe de desenvolvimento com mestrado ou experiência comprovadas na área de desenvolvimento superior a 10 anos | X | ||||
| 25 ou mais membros da equipe de desenvolvimento com nível superior ou experiência comprovadas na área de desenvolvimento superior a 5 anos | X | ||||
| 5 ou mais membros da equipe de desenvolvimento com certificação PMP ou experiência comprovada na área de desenvolvimento superior a 5 anos | X | ||||
| 5 ou mais membros da equipe de desenvolvimento com experiência comprovada como DBA superior a 5 anos | X | ||||
| 5 ou mais membros da equipe de desenvolvimento com experiência comprovada em teste de software superior a 5 anos | X |
Deixe um comentário