desenvolvimento de sotfware

Desenvolvimento ágil de Software com modelação e geração automática de código

10 VANTAGENS para o comprador de software

Muitos projetos de desenvolvimento ou “customização” de software específico, baseiam-se em cadernos de encargos que se focam muito em tecnologia e recursos. Por exemplo, a obrigação que seja em linguagem JAVA, com 50 programadores, durante 3 anos. Esquecem, no entanto, custos escondidos que alguns fornecedores, deliberada ou inadvertidamente, omitem nas suas propostas.

Este documento pretende levantar alguns desses custos e desafiar quem tem a responsabilidade de definir os requisitos de desenvolvimento e implementação, a evitá-los ou minimizá-los nas suas adjudicações. O objetivo é criar mais VALOR para o cliente abrindo a porta a fornecedores e projetos, inspirados em metodologias inovadoras, como o DevOps, Lean IT ou Agile/SCRUM.  Segundo um artigo publicado no Financial Times, algumas destas abordagens podem ser três vezes mais rápidas e com maiores taxas de sucesso que o desenvolvimento tradicional.

1. Prototipagem rápida

  • O fornecedor deverá ser capaz de apresentar num prazo curto um protótipo funcional. Este deve mostrar as caraterísticas técnicas básicas (utilizadores, processo de login, menus, registos e tabelas, reportes,…) e o layout gráfico de base.
  • O prazo de elaboração do protótipo deverá ser quantificado pelo fornecedor para que o cliente tenha uma ideia da eficiência do processo de desenvolvimento.
  • A prototipagem rápida pode mesmo servir, em fase de análise de propostas, para avaliar a eficiência de desenvolvimento dos concorrentes. Eventualmente o cliente poderá estipular um valor para premiar ou pagar, a um ou a todos os concorrentes, na elaboração de uma prova de conceito.

2. Source Code

  • O fornecedor da solução deverá eventualmente, ser obrigado a entregar o código fonte numa linguagem standard que possa ser compilada livre e independentemente de quem criou esse código. C++, C# ou JAVA serão as opções habitualmente mais utilizadas. Isso dará ao cliente o poder de independência do fornecedor (mesmo que não faça uso dele) e autonomia na evolução futura da solução.
  • O fornecedor deverá ser capaz de apresentar um preço para o código fonte da solução a entregar. Por vezes, o código fonte está entregável mas por valores astronómicos ou, não sendo standard, dependente do licenciamento de uma plataforma onerosa.
  • O código fonte deverá, em qualquer dos casos, estar sempre devidamente documentado para minimizar os custos de tratamento por outros futuros programadores.
  • Não sendo possível entregar o código fonte (por se tratar de um produto/pacote de mercado) o fornecedor deverá, como compensação, fornecer outras garantias. Por exemplo o preço para um licenciamento vitalício e ilimitado.

3. Licenciamento ilimitado

  • Muitas organizações iniciam a utilização de um dado software como um dado número de utilizadores e, de repente, função de alguma alteração legislativa, fusão ou associação com outras entidades ou por qualquer outra contingência no seu ecossistema, vêm-se obrigadas a aumentar rapidamente o número de utilizadores. O habitual licenciamento por utilizador, por CPU ou por servidor, pode limitar em tempo e custos ou mesmo bloquear essas mudanças por razões orçamentais. No Estado, por exemplo, poder-se-á ficar parado por um ano até à aprovação do novo orçamento anual e a toda a tramitação administrativa do processo de compra. Assim, os fornecedores de software deverão ser capazes de apresentar nas suas propostas o custo do licenciamento por número ilimitado de utilizadores.

4. Licenciamento vitalício

  • O mesmo se passa relativamente ao licenciamento temporal. Muitos fornecedores de software faturam o licenciamento numa base anual. Com o argumento da atualização tecnológica, imputam ao cliente um custo fixo anual. Se por qualquer razão, por exemplo um sistema de contabilidade que vai ser desativado mas que terá que manter o histórico, o cliente não quiser mais pagar o licenciamento anual ficará numa situação difícil. Nesse sentido, os fornecedores de software devem ser capazes de apresentar nas suas propostas o custo do licenciamento vitalício das suas soluções (com ou sem serviço opcional de suporte e manutenção).

5. Imunidade tecnológica

  • Se uma solução fornecida numa dada tecnologia precisar de evoluir para uma nova tecnologia qual o prazo e custo de tal operação? Qual o grau de dependência ou imunidade tecnológica dessa solução? Os fornecedores de software deverão clarificar nas suas propostas:
  1. se a solução foi programada manualmente e toda a inteligência de negócio está embutida no código (numa dada linguagem e tecnologia);
  2. se foi gerada automaticamente a partir de um modelo onde estão guardadas as regras de negócio;
  3. se trabalha sobre qualquer browser standard ou necessita da instalação de alguma aplicação proprietária em cada posto de trabalho.
  4. quais os prazos e custos típicos de mudança tecnológica da solução, com exemplos históricos.

6. Eficiência de alterações e manutenção evolutiva

  • Segundo um estudo da Barry Bohem, nos processos de desenvolvimento de software em cascata (waterfall) estima-se que o custo de uma alteração na fase de operação/exploração do sistema é de 150 vezes ao custo de uma alteração na fase de requisitos. Por isso os fornecedores deverão ser capazes de apresentar nas suas propostas a relação de custos das alterações nas diversas fases de projeto, para que o cliente possa tomar o controle dos custos de projeto e não ficar refém de um caderno de encargos que vai ficando rapidamente desatualizado ao longo do tempo.
  • Após a finalização e entrega do projeto a mesma questão se coloca para o preço da manutenção evolutiva. Qual a relação entre o preço das alterações funcionais ao sistema em operação/exploração versus o preço de alteração de requisitos iniciais?
  • Caso esta relação seja difícil de medir,  deve tentar-se encontrar uma métrica eficaz ou pedir-se aos fornecedores exemplos específicos de prazos/custos para novas funcionalidades que possam ser introduzidas já depois do sistema implementado.

7. Modelação de software (inspiração indústria 4.0)

  • Sendo a solução de software desenvolvida a partir de modelação e geração automática e, por isso, gozando de imunidade tecnológica (ponto 5.), o cliente deverá poder desenvolvê-la depois autonomamente. O cliente deve poder ficar com o modelo (definições que geraram a aplicação automaticamente). E, por isso, o fornecedor deve apresentar os custos de utilização e licenciamento da plataforma de modelação e geração automática, bem como os custos do modelo.
  • O fornecedor deverá também ser capaz de fornecer a documentação sobre a arquitetura informacional integral da solução (estrutura de dados, relações, regras de negócio e processos) e o respetivo custo.

8. Transferência de tecnologia 

  • O fornecedor deverá ser capaz de apresentar um plano de transferência tecnológica para o cliente. Este deve incluir a formação na utilização da plataforma de modelação e geração automática, de forma a dotar o cliente do conhecimento necessário à sua manutenção e evolução, independentemente desse serviço vir a ser prestado posteriormente pelo fornecedor.

9. Add ins

  • A solução fornecida deverá disponibilizar ferramentas e acessórios que permitam ao cliente ter acesso aos dados para consulta (leitura) avançada, para visualização através de OData e para integração com outros sistemas, nomeadamente de geração de indicadores e reporte. Por exemplo API WebServices que expõem todas as funcionalidades das aplicações.

10. (Ciber)Segurança

  • A solução fornecida deverá respeitar a mais recente legislação europeia e nacional sobre Segurança Digital integrada de acordo com GDPR e NIS e ser fácil e rapidamente adaptável a evoluções futuras destas normas.

Conclusões

Sugere-se aqui o que se deve colocar e o que não se deve colocar num caderno de encargos para desenvolvimento ou “customização” de software de gestão específico, porque um bom caderno de encargos é meio caminho para um projeto bem-sucedido.

Dê espaço à inovação. No caderno de encargos, coloque o WHY, o WHEN e até o WHAT, mas deixe liberdade para o fornecedor definir o melhor HOW.

Sabe o que são os projetos sources sought (nos Estados Unidos) ou pre-commercial procurement (da União Europeia), mais favoráveis a soluções inovadoras?

Mesmo na renovação, pondere substituir o que tem instalado, nomeadamente por valores de licenciamento mais baixos. Aliás a contratação pública já requer, pelo menos, a menção a uma solução equivalente.

Estas são 10 importantes vantagens para o cliente ao adquirir soluções core específicas de software de gestão.  Também podem servir de guia para a redução drastica de alguns dos custos escondidos, resultantes de metodologias de desenvolvimento mais conservadoras, como por exemplo:

  • dependência crescente de uma tecnologia obsoleta
  • dependência crescente de recursos homem/hora
  • dependência crescente de um único fornecedor
  • lentidão no desenvolvimento de novas funcionalidades
  • preços exorbitantes de manutenção e adaptação evolutiva global
  • licenciamentos imprevistos para novos utilizadores e períodos de tempo

E assim dar maior controle de gestão e valor a quem adjudica e gere projetos inovadores nesta área.

____

Nota: Pode consultar algumas minutas de cadernos de encargos de software no site da AMA ou Base.gov onde estas recomendações deverão ser incluídas.