ODS 12

Gasper et al. (2019) afirmam que as metas deste ODS não clarificam objetivamente medidas específicas para alcançar cada uma das metas, mas que “enfatiza abordagens políticas voluntárias e indiretas para alcançar os padrões de consumo e produção sustentáveis”, também afirma que o ODS conta com a “fé na capacidade humana de administrar os impactos ambientais adversos do crescimento econômico sem fim, [..], por meio de inovação tecnológica e cooperação” (GASPER et al., 2019).

Considerando assim que o ODS 12 aborda de forma muito ampla as questões de consumo e produção, adotar pequenas medidas conscientes num processo de desenvolvimento de software já contribui com o objetivo. De maneira geral, todas as medidas sugeridas na presente dissertação se interligam na contribuição direta ou indireta ao ODS 12.

Na prática, o que podemos adotar:

Pilotite, explicado por Lampariello et al.  (2021) como projetos de software que não obtêm êxito já na fase piloto, é um fenômeno que vai na contramão da produção sustentável, já que os recursos utilizados no desenvolvimento do projeto são desperdiçados pois o software não é utilizado. Para evitar este fenômeno, realizar uma pesquisa prévia ao início do desenvolvimento do projeto, buscando sistemas de software semelhantes aos já existentes, se estes têm boa aceitação no mercado e/ou do público-alvo, é uma boa estratégia para verificar se vale a pena iniciar o projeto.

Sugere-se listar alguns destes sistemas de software já existentes e suas principais funcionalidades para fazer um comparativo e a partir daí pensar em funcionalidades diferenciais, inclusive, que contribuam aos ODSs. 

Deve ficar evidente aos stakeholders qual o enfoque do software e como ele se destaca de soluções já existentes e, caso, não pareça viável o desenvolvimento do projeto, por mais que haja interesse e demanda dos stakeholders para produção, criar produtos repetidos ou que não tenham funcionalidades que possam destacar o produto, visando o sucesso da sua utilização, pode criar um produto obsoleto e contribuir para uma produção demasiada de “mais do mesmo”.

Definição clara dos stakeholders: no estudo de revisão sistemática inicialmente desenvolvido nesta dissertação, evidencia-se a importância da identificação de stakeholders do projeto, para que o levantamento de requisitos, alinhamento de expectativas e negociações. Sendo assim, os stakeholders devem ser listados, sejam eles usuários diretos do software, clientes, órgãos governamentais, dentre outros, pois estes serão pontos fundamentais na disseminação das informações sobre os ODSs e as medidas para contribuição com esses ODSs que serão adotadas durante o projeto, contribuindo à Meta 12.8. 

Ao término do projeto, seja na fase piloto, ou nas entregas parciais, os stakeholders são as primeiras pessoas que devem ter uma boa aceitação do projeto.

Objetivos e diferenciais da proposta: é necessário evidenciar a geração de valor que o projeto trará a seus usuários, quais os diferenciais que o software possuirá, para que ele não caia no fenômeno da pilotite. Explicitar essas informações justifica o desenvolvimento do projeto e motiva, além dos stakeholders envolvidos, a equipe que vai trabalhar, dentre outros possíveis personagens envolvidos. A contribuição ao ODS 12 vem do fato de o objetivo do desenvolvimento do projeto ser pautado em um software que realmente obtenha êxito na sua implantação, não produzindo um produto irrelevante.  

Tendo as funcionalidades abrangidas e descartadas do escopo bem definidas, evita-se que sejam criadas, por parte dos stakeholders, expectativas que não serão atingidas e fazendo com que as funcionalidades abrangidas no escopo possam ser desenvolvidas de maneira consistente, pois a partir daí a equipe de desenvolvedores poderá se atentar a questões quanto a reutilização de código, uso de padrões de programação, automação de processos, dentre outros fatores, que contribuirão com os princípios de qualidade de software definidos pela ISO 25010:2011. Também é a partir dessa definição preliminar de funcionalidades que se pode trabalhar a elicitação de requisitos do projeto, sendo que em “sistemas de grande porte é o caso de existir uma fase da engenharia de requisitos claramente identificável antes de se iniciar a implementação do sistema” (SOMMERVILLE, 2011 p.58). Em projetos ágeis, os requisitos podem variar ou sofrerem alterações ao longo do desenvolvimento, sendo assim podem ser escritos como histórias de usuário, por exemplo (SOMMERVILLE, 2011). Mas ainda assim é importante ter um ponto de partida.

Definição da equipe de desenvolvimento: uma equipe com papéis definidos clarifica as necessidades de conhecimento para que as funções de cada um seja desempenhada e, também, para que uns não sejam sobrecarregados em detrimento de outros. Conforme Imtiaz et al. (2016) a divisão das tarefas em uma equipe deve considerar, dentre outros, fatores como: experiência, conhecimento e disponibilidade dos membros do time. A equipe deve estar a par das medidas adotadas para a contribuição no cumprimento dos ODSs, a fim de que uma cultura de sustentabilidade possa ser disseminada,  contribuindo para a Meta 12.8.

Reutilização de código e boas práticas de programação: verificar se há a possibilidade de reutilizar algum código já produzido pela própria equipe de desenvolvedores ou disponibilizado de maneira aberta a fim de economizar tempo e recursos de programação. A equipe de desenvolvimento deve ter em mente o princípio da manutenibilidade, ou seja, o código não ficará estático para sempre, é necessário que seja possível alterá-lo facilmente se necessário e reutilizá-lo (todo ou em partes) em outros projetos, assim enquadrando-se no princípio de manutenibilidade num todo, especialmente nos critérios de  reusabilidade e modificabilidade da ISO 25010:2011. Jha et al. (2005) afirmam que a reutilização de código aumenta a produtividade e a qualidade do software, sendo que o reuso não descarta a personalização conforme a necessidade.

Medição de gasto energético: apesar deste item contribuir diretamente com o ODS 7, as medidas que podem ser tomadas para evitar o desperdício energético durante o desenvolvimento do projeto e uso do software contribuem indiretamente ao ODS 12.
 

Interoperabilidade:  a interoperabilidade de um sistema pode ser um dos fatores chave para seu sucesso,  mesmo que não seja uma demanda imediata, deve estar previsto o caso de num futuro, o sistema precisar ser interoperável com outros, sem demandar grandes esforços de desenvolvimento. Destaca-se, por exemplo, sistemas de software voltados à área da saúde, a adoção de padrões internacionais que garantam que o sistema seja interoperável com outros sistemas é de suma importância. Segundo Tapsoba et al. (2020): “Para uma melhor coordenação dos serviços de saúde, a maioria dos hospitais precisa se comunicar por meio do compartilhamento de conhecimento. A interoperabilidade entre os sistemas de informação hospitalar é, portanto, um imperativo” (TAPSOBA et al., 2020).  Considera-se também o item de interoperabilidade que está no princípio da compatibilidade da ISO 25010:2011, pois com os incontáveis sistemas de software que existem em diversas áreas atualmente, um software projetado para existir apenas individual e isoladamente vai na contramão de qualquer possibilidade de inovação, inclusive podendo comprometer o sucesso do produto.
Confiabilidade e segurança: os usuários precisam sentir-se confortáveis ao usar o software, principalmente se ele conta com preenchimento de dados, é necessário que o usuário se sinta seguro na utilização, que o sistema passe confiabilidade, que conte com políticas de privacidade quando for o caso, do contrário as pessoas podem vir a abandonar ou evitar o uso do sistema.  Lampariello et al.  (2021) citam a importância de considerar o “fator humano” ao desenvolver um software, inclusive quando este fator é negligenciado, há chances de cair no fenômeno da pilotite.

É importante que sejam realizados testes automatizados ao longo do projeto para evitar e/ou diminuir a ocorrência de erros na aplicação, porém, conforme o público-alvo, testes de caixa preta também são de suma importância. Swartz et al.  (2021) afirma que fatores relacionados às personas envolvidas no processo podem ser mais desafiadores do que questões tecnológicas em si. No estudo de revisão sistemática realizado para esta dissertação é evidenciado as dificuldades de implementação de sistemas de software na área da saúde devido às diferenças culturais, sociais e geográficas em que os usuários estão inseridos. Portanto, cenários de teste de caixa preta bem escritos e objetivos conforme os critérios de aceitação das funcionalidades, contribuem para a abordagem centrada no usuário citada anteriormente e aumentam a qualidade do software.

Questões como um fluxo de sistema intuitivo e otimizado, com todas as funcionalidades atendendo as expectativas, de acordo com o contexto, devem estar incluídas no cenário de teste.

Assim, além de contribuir indiretamente ao ODS 12, também contribuem ao princípio de usabilidade e ao critério de testabilidade do software, descrito no princípio de manutenibilidade da ISO 25010:2011.

Ao final do projeto num todo, ou ao final de entregas parciais, dependendo da abordagem utilizada, deve ser avaliada se a recepção do produto de software, de maneira geral, é positiva, pois os stakeholders devem estar satisfeitos com o produto entregue para que, quando for colocado em produção, obtenha êxito. Por mais óbvio que isto pareça em qualquer projeto de software, do ponto de vista dos ODSs, um software com potencial de sucesso, conforme os princípios de qualidade da ISO 25010:2011 e baseado nos fatores que objetivaram o alcance de ODS e Metas, contribui ainda mais para o ODS 12 e, logo, para todos os outros adotados durante o processo de desenvolvimento.

Por fim, após o produto final ser homologado, deve-se viabilizar a possibilidade de divulgar os esforços que foram tomados consonantes aos ODSs, pois é importante que estas informações sejam divulgadas para que o maior número de pessoas possível, além da equipe de desenvolvimento e stakeholders, tenha conhecimento sobre os ODSs, o que contribui para a Meta 12.8.