O Sr. Fernando França do Desconstruindo me mandou um e-mail falando sobre seu problema com o fornecedor de um ERP que utiliza o PostgreSQL, mas deixou de dar suporte para novas versões. A última versão que ele suporta é a 7.4 lançada há 5 anos. Para o ritmo de desenvolvimento do PostgreSQL isso é muita coisa mesmo. No entanto, o nosso amigo é brasileiro e não desiste nunca… foi atrás do fornecedor que lhe devolveu a clássica resposta: “O PostgreSQL não possui suporte oficial do fornecedor”.

Quando escuto uma coisa destas, respiro fundo e me preparo para uma longa conversa que se segue abaixo. A conversa não é nova, já foi discutida a exaustão em inúmeros lugares, inclusive aqui e esta infelizmente não será a última. Graças a campanhas difamatórias de grandes empresas este assunto vem a tona sempre que alguém deseja se opor a algum tipo de mudança.

Vejamos os argumentos que estão na ponta da língua de quem usa este tipo de argumento:

• Eu preciso ter uma empresa que eu possa processar se houver algum problema grave.
  • Se você olhar o kernel do Linux ou do FreeBSD, você verá que não há realmente qualquer garantia por parte do fornecedor de que aquilo irá funcionar adequadamente. O mesmo vale para qualquer software livre que você conheça. No entanto isto não impede que ele seja utilizado em ambientes críticos, por grandes instituições no Brasil e no mundo. Da NASA, forças armadas e grandes bancos, todos confiam em softwares livres para tocar o seu negócio. Qual o problema de se confiar no PostgreSQL?
  • Você acredita realmente que alguém fornece um software e realmente garante 100% o seu funcionamento? Olhe as licenças de software dos grandes fornecedores e você verá que todos possuem cláusulas onde especificam claramente que não se responsabilizam pelo mal funcionamento do Software. Você não compra uma garantia, você compra uma marca.
  • Você acredita realmente que vai processar a IBM, Oracle ou Microsoft? Já pensou se as pessoas conseguissem processar a Microsoft a cada vez que o Windows apresentasse uma falha crítica que causasse prejuízo para alguém? Porque você acha que todos estes softwares fazem questão de que você concorde com a sua licença de uso antes de utilizar ele?
• Eu preciso de suporte oficial.
  • Você precisa de suporte de qualidade. O oficial, fica por conta do fornecedor que tem quer lhe vender o suporte. Ocorre que quando o software não é livre, apenas uma empresa tem o código fonte do software e somente ela sabe realmente como ele funciona. No caso do software livre, você pode escolher a empresa que lhe dará este suporte e pode escolher trocar de empresa se você não gostar dela. Se você não estiver satisfeito com o suporte de um grande fornecedor de uma solução proprietária, você não tem outra opção a não ser pagar mais ou substituir toda a solução.
  • Se você não estiver satisfeito com o suporte oferecido pela documentação oficial, IRC ou listas de discussão por e-mail você pode contar com o suporte comercial de várias empresas ou de consultores especializados. Por fim, você pode contar ainda com uma série de serviços de hospedagem com suporte ao PostgreSQL
  • Você precisa de atualizações de segurança e correções de bugs. Se você não paga o suporte oficial de um fornecedor de software não livre você fica sem as atualizações do software. No caso dos software livres isto não ocorre. Você nunca vai ficar na mão por não ter pago o suporte num momento de dificuldades financeiras.
• Eu preciso de uma empresa que me forneça suporte 24×7.
  • Você tem idéia de quanto custar o suporte 24×7 para uma solução Teradata, Oracle ou DB2? Adicione alguns zeros a direita e você chegará num valor razoável. Quem tem este tipo de suporte paga milhões. Se você quiser suporte 24×7 em algum Software Livre, basta pagar que você o terá.
  • Já existem grandes empresas de software que prestam suporte ao PostgreSQL, entre eles a Red Hat e Sun. Eles tem porte suficiente para lhe oferecer um suporte 24×7 nas condições mais agressivas que você possa desejar. É claro que isto não vai lhe sair barato…

• Eu preciso de profissionais certificados.
  • Um certificado é um pedaço de papel que uma pessoa recebe após fazer uma prova. Toda pessoa que possui a CNH (Carteira Nacional de Habilitação) tem que fazer uma prova escrita e uma prática. A maioria das certificações se limitam a uma prova escrita. Você acredita que os motoristas brasileiros são bons? E os profissionais certificados, você acredita que um certificado atesta a sua aptidão profissional?
  • Se você precisa de profissionais qualificados, há centros de treinamento com excelente qualidade com cursos adhoc, in company e com boas opções de conteúdo.

É claro que muitos fornecedores acabam acreditando nos bilhões de dólares investidos em propaganda e não na palavra de um simples blog. Mas a questão é que muita gente usa o PostgreSQL e outros softwares livres, tem suporte de qualidade e vão muito bem, obrigado. A maioria deles não grita isto aos quatro cantos por aí, mesmo porque, isto pode ser um diferencial competitivo. Mesmo assim sabemos que existem inúmeros casos de sucesso declarados que mostram a maturidade do PostgreSQL em ambientes corporativos.

O curioso neste caso é que a empresa em questão chegou a desenvolver uma versão para o PostgreSQL. Aqui entra um bocado de especulação pela minha parte. Uma especulação plausível, que pode não se aplicar ao caso em questão, mas certamente se aplica a outros casos. O fato é que há uns 5 anos atrás, na época do estouro do Kurumin, o Brasil experimentou uma certa euforia em torno do Linux. Muita gente apostou que o Software Livre seria a solução para cortar drasticamente os custos de TI e sairam implementando algumas soluções por aí de forma caótica. O resultado para quem partiu para este tipo de abordagem foi invariável: falharam miseravelmente. Ocorre que o Software Livre diminui o TCO da sua empresa, mas não a curto prazo. Inicialmente os custos podem até ser mais altos devido às demandas de treinamento, consultoria e migração. É a médio e longo prazo (3 a 5 anos) que o TCO começa a mostrar uma redução significativa.

Muita gente saiu criando versões de seus produtos compatíveis com plataformas livres. A Borland chegou a lançar o Kilix, uma versão do Delphi para Linux. Mas, muitos desistiram no caminho. Alguns voltaram para os braços das plataformas proprietárias. Muitos migraram de forma irresponsável, outros não souberam se adaptar ao ecosistema do Software Livre e alguns receberam propostas indecorosas para frear suas ações em direção ao Software Livre.

O fato é que se você fornece software proprietário para rodar em uma plataforma livre, você vai descobrir um novo tipo de cliente. Um cliente que começa a gostar da idéia de ter independência de fornecedor. Não se trata aqui de guardar um catatau de códigos fontes do fornecedor na gaveta. Trata-se da opção de não ficar amarrado a um fornecedor para o resto da vida.

Este é o tipo de liberdade que muitos fornecedores de software proprietário não gosta. Afinal, se é verdade que o lucro no mercado de software advém de serviços e não de licenças, ter o monopólio na prestação de serviços em algum nicho é um grande negócio. Se você usa Java, você pode escolher o SO que desejar e SGDB de sua preferência para rodar a sua aplicação. No entanto, se você utiliza o Oracle Application Server, que utiliza o Java e o Apache, você só pode utilizar o SGDB Oracle e só a Oracle pode lhe dar suporte. Você vai encontrar fenômeno semelhante se você utilizar o WebSphere da IBM. Imagine agora que você resolve implementar uma solução de um fornecedor de ponta a ponta? Há fornecedores que podem lhe prover servidores, SO, SGDB, Web Server, ERP, BI e o que mais você possa imaginar. Bom, se você fizer isso, é melhor comprar um bom lote de ações desta empresa, pois você estará tão preso que é melhor ser sócio dela.

Conclusão, se você quer que um fornecedor de software proprietário seja homologado numa plataforma livre, você deve ter muita bala na agulha, caso contrário, o fornecedor dificilmente lhe dará ouvidos.

Tags: enterprise, FLOSS, PostgreSQL

2006 foi um ano em que o Linux, GNU/Linux, Software Livre ou Software de Código Aberto ganhou muita força.

- A RedHat, após figurar entre as 100 maiores empresas da Nasdaq foi para a Bolsa de NY.
- A Oracle comprou o InnoDB e Lançou o Unbreackable Linux,
- Oracle, IBM e Microsoft liberam versões “shareware” de seus SGDBs proprietários, em resposta aos avanços dos SGDBs livres.
- O projeto Mono lança sua versão do Forms tornando-se uma alternativa cada vez mais viável ao .Net
- A Sun decide lançar o Java com a licença GPL. Em 2006, pequenas partes do Java começam a serem liberadas.
- Acordo entre a Novell e a Microsoft
- O lançamento do Windows Vista aparenta cada vez mais um tiro no pé da Microsoft.

Há tempos atrás eu escrevi sobre o avanço do Software Livre no mercado corporativo, hoje parece que a guerra das patentes está se intensificando cada vez mais…

Em 2006,

• A Microsoft recebeu 932 patentes.
• A Sun recebeu 648 patentes.
• A Oracle recebeu 164 patentes.
• A Novell recebeu 9 patentes.
• A IBM recebeu 4 patentes.
• A Red Hat recebeu 3 patentes.
• A Netscape recebeu 2 patentes.

Achando um pouco estranho a diferença no número de patentes entre a Microsoft e IBM. É possível que o Google não tenha catalogado todas as patentes de 2006 ainda. Resolvi entrar direto na boca do leão: o “United States Patent and Trademark Office“. Lá a busca não é tão simpática como a do Google, mas vejamos o que encontrei. Lá eles tem um banco de dados com todas as patentes de 1980 até hoje:

• A Microsoft recebeu 12158 patentes.
• A IBM recebeu 4527 patentes.
• A Oracle recebeu 2539 patentes.
• A Novell recebeu 718 patentes.
• A Sun recebeu 18554 patentes.
• A Netscape recebeu 128 patentes.
• A Red Hat recebeu 33 patentes.

Isto significa que:
- TODOS registram patentes!
- A Microsoft e a Sun são de longe as que mais registram patentes.
- Em 2006 somente a Microsoft, Sun e Oracle receberam um volume significativo de patentes.

Temos que lembrar também embora existam promessas de algumas empresas de não processar outras, a guerra das patentes está apenas começando… a cada dia surgem novas alianças na indústria de software para se prepararem para as grandes batalhas que virão. Por enquanto, somente vemos uma guerra fria, com morte por afogamento da SCO sendo anunciada. Mas as armas atômicas estão aí e as ações para desarma-las ainda são muito tímidas, e a cada anos novas patentes vão se somando, até o dia em que nenhum desenvolvedor possa ligar seu computador sem ter que pagar para alguém.

Enquanto o Samurai Stallman aplaude a liberação do JAVA usando a GPL, 648 novas patentes caem nas mãos da Sun. Esta novela está ficando interessante, vejamos o que vai acontecer em 2007

Tags: enterprise, IBM, linux, Microsoft, Netscape, Novell, Oracle, patent, Red Hat, Sun

Conclusão

Parte 1 - Comprar pronto, desenvolver internamente ou desenvolver externamente?
Parte 2 - Metodologia para compra de software
Parte 3 - Requisitos para compra de software

Para quem achava que comprar um software pronto é uma opção bem mais simples do que desenvolver a partir do zero, este processo demonstra que isto pode ser verdadeiro, mas não significa que a compra do software não seja um processo complexo e trabalhoso. Algumas vezes é possível que ao final do processo se chegue a conclusão de que não existem soluções tecnicamente viáveis para as suas demandas e decidir por se lançar a desenvolver um novo software.

Ignorar completamente o processo - aqui descrito de forma simplificada - implica numa aposta de alto risco, com consequências possivelmente desastrosas. Os fornecedores possuem uma equipe de vendedores treinada para lhes dar respostas fáceis e lhe convencer de que o processo pode ser realmente simples.

É por isso que eu gostaria aqui de ressaltar a importância de serem considerados os requisitos técnicos na escolha de uma solução de software. As fábricas de software se esforçam muito em oferecer software com uma aparência agradável, repletos de funcionalidades interessantes que nem sempre são úteis na prática. No entanto, alguns gestores tendem a acreditar que isto é suficiente para definir um software que atenda às suas necessidades. Este documento tem por fim, demonstrar de maneira rápida, como avaliar os riscos do fornecedor não cumprir as suas promessas, demorando mais tempo que o previsto para implantar a solução e corrigir problemas, colocar em funcionamento as funcionalidades prometidas e cumprir prazos estabelecidos.

De acordo com a importância e complexidade do software a ser adquirido, pode-se levar em conta um grande número de requisitos para filtrar soluções inadequadas e classifica-las de forma objetiva. Foram listados aqui cerca de 100 possíveis requisitos técnicos de software que podem ser utilizados. É claro que alguns itens podem ser considerados supérfluos e podem-se notar itens importantes que não constam nesta lista. A categorização dos itens aqui proposta também foi realizada de forma a facilitar a escrita e a leitura deste longo documento. Você provavelmente irá querer rearranjar estas categorias em termos técnicos mais precisos.

Você poderá entender que alguns itens ou grupos de itens tem maior importância que outros e atribuir pesos diferentes para eles. Os requisitos técnicos aqui descritos representam apenas uma fração da nota final que deve incorporar também os requisitos funcionais e o preço da solução para compor uma nota final.

Agradecimentos

Gostaria aqui de agradecer alguns colegas cuja valorosa contribuição tornou a criação deste texto possível:

• Carla Nogueira
• Franklin Benini
• Gilberto de Oliveira
• Jadelson Silva
• Kazuaki Hirota
• Marcos Oliveira
• Maiara Lessa
• Sheila Pontes
• Vanessa Paiva

Tags: enterprise, software

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.

Ítem	C	O	MD	D	PD
Uso de 3 camadas				X
Uso de MVC			X
Uso de framework de software					X

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 Análise e projeto Desenvolvimento Testes			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

Tags: assessment, best pratice, CMMI, Documentation, enterprise, software

Metodologia para compra de software

Parte 1 - Comprar pronto, desenvolver internamente ou desenvolver externamente?
Parte 3 - Requisitos para compra de softwareParte 4 - Conclusão

Bem, você optou por comprar um software pronto. Então chegou a hora de escolher a solução que melhor atende às suas necessidades e que se encaixe no seu orçamento. É claro que você já sabe exatamente como deve ser o software que você necessita… não é?

É claro que não! Um software corporativo é muito grande e complexo. É muito difícil alguém conhecer exatamente todas as regras de negócio envolvidas, todos os processos que vão envolver o software e ainda conhecer a melhor tecnologia a ser utilizada. Você deverá reunir uma equipe, talvez com o apoio de uma consultoria externa para ajudar a definir quais são as suas demandas reais. Aqui, já partimos do principio que toda a implantação de software tem como impacto uma reengenharia de processos e ao mesmo tempo a necessidade de se manter o foco nas demandas centrais para não buscar uma aplicação com um custo impraticável.

Aqui, existe uma boa bibliografia que indica alguns caminhos a seguir. Em geral o processo conta com um levantamento de requisitos técnicos e funcionais entre os potenciais usuários, gestores e equipe de TI. Deve-se levantar também quais requisitos são essenciais e quais são desejáveis. Quais precisam ser implantados primeiro e quais podem ser implantados posteriormente.

Feito isto, deve se ir a campo e procurar empresas de software que forneçam soluções que aparentemente atendam às suas expectativas. Visitar a empresa na sua sede, assistir demonstrações e conhecer a sua fábrica de software são essenciais. Deve-se enviar um questionário para cada fornecedor com a sua lista de requisitos que você levantou, para que você possa comparar as soluções. Você também deve agregar as suas próprias observações de forma sistemática para cada visita realizada às empresas. É fundamental que a mesma equipe visite todos os fornecedores para que eles realizem a comparação de forma mais precisa.

Outro passo importante é visitar outras empresas onde o sistema já esteja implantado. Para isso solicite uma listagem de locais onde o sistema foi implantado e agende visitas nestes locais sem avisar o fornecedor. Não vá em locais indicados pelo fornecedor. Verifique se as funcionalidades destacadas pelo fornecedor conferem com as observadas em produção.

Feito isto, você deve planilhar todas estas informações e solicitar orçamentos dos fornecedores que atenderam as exigências mínimas requeridas. Você deve estabelecer uma métrica de pontuação para chegar a uma nota final de avaliação dos sistemas. Aqui, a questão mais difícil é ponderar qual é o peso de cada área. Você não deve jamais se deixar levar apenas pelo preço ou pelas funcionalidades apresentadas. É preciso balanciar vários fatores observados:

• Reputação da empresa no mercado
• Qualidade, tamanho e estabilidade da equipe envolvida no desenvolvimento e manutenção
• Metodologia adotada no desenvolvimento e manutenção
• Carteira de clientes e satisfação dos mesmos
• Qualidade e veracidade das informações fornecidas
• Funcionalidades presentes
• Maturidade das regras de negócio
• Técnologia adotada
• Custo de manutenção
• Custo de implantação

Existem conjuntos de indicadores e pesos bastante utilizados na aquisição de software. No entanto, estes pesos são apenas modelos que você deve adaptar a sua realidade e percepção de importância. Muitos destes itens são de avaliação subjetiva e tem que ser utilizados com cautela e bom senso. Na esfera pública, isto se torna bem mais complexo, uma vez que é preciso realizar uma licitação do tipo Técnica e Preço onde os critérios de avaliação da nota técnica tem de ser estritamente objetivos.

É impossível abordar aqui questões pertinentes às regras de negócio de devem compor a nota de um software, pois cada organização terá demandas específicas. No entanto, existem necessidades técnicas na área de informática que não são menos ou mais importantes que as regras de negócio em si. Ainda assim, os critérios técnicos são muitas vezes relevados para um segundo plano na escolha de um software. Estes critérios só mostram sua importância quando o sistema precisa ser adaptado ou depois que ele entra em produção. E neste momento costuma ser tarde demais para voltar atrás sem causar um grande estrago.

As funcionalidades de um sistema são fáceis de serem demonstrar e costumam satisfazer a maioria dos gestores, porém, a área de TI deve assegurar que o software seja robusto, flexível, confiável, rápido, etc. Estas questões são todas de responsabilidade da área de TI pontuar uma a uma e definir métricas para a sua avaliação.

Dependendo da situação, os pesos da aplicação podem variar bastante:

• Sistemas utilizados por um grande volume de usuários tem grande vantagem se rodarem via WEB. No entanto inserção bruta de grande volume de dados ainda ocorrem de maneira mais eficientes em interfaces GUI ou mesmo em modo texto.
• Sistemas que podem ser acessados por um público externo devem ter um cuidado especial com a usabilidade e acessibilidade.
• Sistemas que devem se integrar com outros sistemas devem suportar padrões abertos de comunicação.
• Sistemas que envolvam a manipulação de informações sensíveis devem ter um cuidado especial com a segurança e com a auditoria.
• Sistemas que envolvem muitas transações concorrentes devem ter um cuidado especial em relação ao controle de transações e o uso de um bom SGDB.
• Sistemas com regras de negócio complexas devem utilizar modelos com 3 ou mais camadas.
• Sistemas de missão crítica que admitam um downtime muito pequeno devem ser desenvolvidos com ferramentas robustas e confiáveis.
• Sistemas que devam entrar em operação por vários anos devem dar prioridade para tecnologias e padrões abertos.
• Comprar o código fonte de um software sem uma excelente documentação é como comprar uma Ferrari sem freios.
• Softwares que dependam de legislação local devem ter casos de implementação local e equipe de desenvolvimento local.

Tags: assessment, enterprise, software