Software como serviço (SaaS) e a melhoria contínua de software

Qualidade em software

Uma das questões primordiais para se alcançar qualidade de software é a melhoria contínua dos processos envolvidos no desenvolvimento.

De acordo como o Capability Maturity Model for Software (CMMS), criado inicialmente pelo Software Engineering Institute (SEI) e hoje mantido pelo Capability Maturity Model Institute (CMMI), existem cinco níveis de maturidade para estes processos, que vão do inicial ao otimizado (ou otimizando)^[i].

Segundo o CMMS, a maturidade do desenvolvimento de software (software process maturity) em uma empresa alcança seu maior nível (optimizing, nível 5 na especificação) quando seus processos são continuamente melhorados, baseados, entre outros aspectos, num retorno (feedback) quantitativo (mensurável) dos processos.

Antes mesmo, no nível 4 (gerenciado), já preconiza o modelo que é preciso ter entendimento e controle quantitativo tanto do processo quanto do produto (software).

O problema é que depois do software estar pronto e ser implantado no ambiente do usuário, pouco ou, muitas vezes, nenhum feedback existe para o desenvolvedor, exceto quando algum problema grave acontece e é necessário alguma intervenção, ou alguma mudança drástica de fatores externos exige uma mudança profunda no software (uma nova legislação fiscal, por exemplo).

As estatísticas de uso do software, no geral, são escassas. Alguns formulários de satisfação são adotados em alguns casos, mas não possuem a riqueza de informação que se obteria se pudéssemos monitorar o uso em tempo real, escolhendo os parâmetros (indicadores) apropriados e obtendo informação objetiva, em lugar da emotiva, da iteração entre o ambiente, software e o usuário.

Exemplos de tentativa de se coletar dados de uso são vistos hoje em dia quando instalamos programas como navegadores, anti-virus, ambientes de desenvolvimento e outros aplicativos, que solicitam autorização para coletar e enviar dados estatísticos sobre o uso (anonymous usage statistics).

Alguns também solicitam permissão para enviar informações quando ocorre uma falha (crash reports).

Mas, para a maioria dos projetos de desenvolvimento de software, não vemos a disponibilidade desta valiosa fonte de informação.

Essas informações seriam úteis para a melhoria do processo de desenvolvimento e, consequentemente, de novos produtos.

Outra questão a ser enfrentada, no que se refere a qualidade de software, é a contradição entre prazo e custo do desenvolvimento e entrega dos requisitos (necessidades do cliente).

Quando desenvolvemos um novo produto (ou serviço), sabemos que mudanças no projeto ocorrerão no decorrer do desenvolvimento.

Parte importante do gerenciamento de projetos é justamente manter o escopo do projeto dentro de certos parâmetros, caso contrário, o projeto corre o risco de não ter sucesso – não conseguir cumprir com seu prazo, custo, escopo - gerando insatisfação para todos os envolvidos.

Se isso é uma realidade para os produtos de engenharia em geral, é uma verdade irrefutável quando nosso produto (ou serviço) é software.

Mudanças nos requisitos (necessidades do cliente) são uma certeza.

O framework Scrum, por exemplo, tem como princípio que o documento que identifica esses requisitos (product backlog) deve ser “dinâmico, constantemente mudando para identificar o que o produto precisa para ser apropriado, competitivo e útil”^[v].

Várias são as razões para que os requisitos de software mudem ao longo de um projeto e com mais frequência, diríamos, que em outros tipos de projetos.

Temos, de um lado, a deficiência do usuário em dizer o que quer e, também, em reconhecer (validar) que aquilo que lhe foi apresentado é o que ele quer.

Do outro lado, o desenvolvedor também não consegue, muitas vezes, compreender as necessidades do usuário, levando a requisitos equivocados ou incompletos.

Os modelos de representação (UML, DER, etc), ainda que visuais, não transmitem para o usuário o mesmo nível de entendimento do produto que uma maquete de um edifício, por exemplo.

Além disso, na área de software, mudanças ocorrem muito mais rapidamente que em outras áreas de engenharia e podemos nos deparar, no meio de um projeto, com tecnologias que, antes economicamente inviáveis, agora tornaram-se acessíveis, fazendo com que desejos do cliente que eram impossíveis de serem atendidos poucos meses atrás possam agora ser atendidos.

O mesmo não ocorre, na mesma escala de tempo, na construção civil, ou na indústria automobilística, entre outros. O preço dos materiais de construção ou as técnicas construtivas não evoluem tão rapidamente como a tecnologia na área de TI.

O problema enfrentado pelas empresas (produtoras) de software é como atender as necessidades do cliente, que não apenas se alteram, mas se ampliam durante o desenvolvimento do software, sem comprometer o orçamento do projeto, o prazo de entrega, recursos necessários e, além de tudo, conseguindo obter lucro.

Se novos requisitos forem acrescentados ou se os já descobertos se alterarem a todo momento (modificando o escopo), torna-se extremamente difícil manter os outros elementos do triângulo custo-prazo-escopo na sua posição inicial.

O PMBOK classifica estes fatores - e também outros, como qualidade, risco, recursos, etc - como restrições conflitantes, cuja relação se estabelece de tal forma que a mudança em um deles provavelmente gera mudança em outro(s)^[vi].

Se tivermos de rever o prazo estabelecido para a entrega do produto, possivelmente, também os valores inicialmente previstos sofrerão alteração, etc.

Corremos o risco de enfrentar ou o descontentamento do cliente, com prazos maiores e/ou custos mais elevados, ou prejuízo para a empresa, tornando o negócio economicamente inviável.

Software como serviço (SaaS) e melhoria contínua de software

No modelo de desenvolvimento em que o software é visto não mais como um produto a ser entregue, pronto e acabado, mas como um serviço oferecido ao usuário, este difícil equilíbrio pode ser mais facilmente encontrado.

Podemos melhorar a qualidade do software continuamente, não existe um momento em que o produto (agora serviço) será enviado para o cliente, saindo do âmbito da organização, não sendo mais possível melhorá-lo senão em novas versões ou atualizações; ele está continuamente em uso e também continuamente em evolução.

Em geral, quando se fala em SaaS, as vantagens econômicas, especialmente para o cliente, são as mais mencionadas.

A Intel, em matéria relacionada ao tema, coloca a redução de custos e riscos como principais razões para adotar o SaaS^[vii].

A Microsoft coloca redução de custos a curto prazo como razão número um, de uma lista de cinco, ao falar das vantagens de se adotar SaaS^[viii].

Apesar de serem grandes as vantagens econômicas para o cliente (e também para os produtores de software), em potencial, com a adoção do SaaS, tão importante quanto estas é a capacidade de se conseguir oferecer um produto (no formato de serviço) que está não apenas atualizado (livre de erros) mas cada vez mais completo, usufruindo das melhores técnicas e tecnologias mais atuais, do conhecimento baseado na observação do uso do software (relatórios de uso, falha, etc) e do próprio amadurecimento da equipe de desenvolvimento.

As empresas de software podem manter uma equipe de desenvolvimento trabalhando no serviço (software) sem a pressão de um prazo de encerramento, pois agora este prazo não necessariamente existe.

A produção de um software em vez de começar como um projeto (que possui uma data de fim, um prazo para ser encerrado) seria, após iniciada, contínua, um processo, no qual se busca, como deveria ocorrer em todo processo de negócio gerenciado modernamente, a melhoria contínua.

O cliente se beneficia com um produto (serviço) cada vez melhor, capaz de atender mais plenamente suas necessidades.

As empresas que produzem software não apenas se beneficiam ao poder oferecer o mesmo software para vários clientes (com as devidas customizações), mas também fica claro que como o conhecimento do domínio do problema pela equipe de desenvolvimento se expande continuamente, o custo da implementação de novas funcionalidades, novas melhorias, deverá, em geral, ser menor, consumir menos tempo e recursos.

Novas tecnologias e soluções podem ser utilizadas para atender necessidades, novas ou não, tão rapidamente quanto se tornem disponíveis.

Apontamentos finais

O conceito de SaaS tem crescido muito nos últimos anos.

Este novo paradigma de desenvolvimento de software, além das vantagens econômicas, muito faladas, tem em si a possibilidade de equipar os desenvolvedores com o ferramental necessário para se alcançar o tão almejado melhoramento contínuo da qualidade do software.

Cada vez mais, com a computação nas nuvens se tornando mais acessível para as empresas, maior velocidade de acesso à internet, melhoria nas ferramentas do lado do cliente (linguagens de scripts cada vez mais potentes, por exemplo), devemos ver um aumento na adoção do SaaS como forma de se consumir software.

Sonho de qualquer engenheiro seria poder modificar seu projeto enquanto está sendo utilizado pelo usuário, sem precisar torná-lo indisponível.

Imagine se um engenheiro civil pudesse rever o projeto de um edifício e, ao perceber que o desenho não aproveita a iluminação natural tanto quanto imaginado, porque, digamos, a incidência de nuvens na região é diferente do imaginado durante o projeto, fosse possível atualizar a planta dos imóveis ou mesmo mudar de posição o edifício todo.

Sonho bastante irreal para a maioria das engenharias, na engenharia de software estamos prestes a presenciar uma revolução em que mudanças tão complexas ou mais (em software, claro) serão lugar comum.