“Vestível Controlador” pode ter sido projetado para falhar

por Jade Scobri | Curitiba, Brasil

As novas informações recebidas em exclusividade pela SBC Horizontes levantam a possibilidade do vestível controlador ter sido deliberadamente projetado para falhar. Uma falha no iWear foi responsável pela paralisação das funções motoras da piloto do DX486 que caiu com 113 pessoas a bordo em agosto passado. Até o momento, o programador Malcom Pila (foto) é o ´único indicado pelo caso, que segue em segredo de justiça.

^{Malcom desabilitou suas contas nas redes sociais após ser indiciado. Na postagem em sua conta no Koo app (foto), o programador relatou}^{ser alvo de ameaças e ataques haters desde que seu código vazou na internet.}

A reportagem teve acesso à documentação elaborada para o projeto, incluindo os requisitos, documentação do processo de desenvolvimento, e planejamento da equipe. Nossa fonte, que tem conhecimento detalhado sobre o projeto do iWear, explicou que muitos problemas poderiam ter sido evitados se o projeto tivesse sido elaborado com cuidado desde o seu início. Esses problemas podem sugerir que Malcom não é o único responsável pelo caso.

“Aqui na Vina Systems nós usamos um modelo de processo inspirado no Scrum. Para agilizar o trabalho, a Vina tem uma equipe formada por profissionais da área comercial e da área técnica que definem o backlog do produto, que é o conjunto geral de requisitos que esse produto precisa satisfazer. O problema é que esse backlog é apenas um conjunto de post-its que documentam Histórias de Usuário que o produto deve implementar. E aí quando o processo avança para estágios de modelagem e implementação, tem muita margem para erro de entendimento das coisas.”

Outro problema, segundo a fonte, é que esse backlog do produto raramente é revisado e atualizado, como deveria ser feito. “No Scrum, um projeto deve poder ser constantemente adaptado a mudanças. Mas isso não ocorria na prática. O papel do Product Owner, responsável por gerenciar, definir e ordenar as prioridades dos itens do Backlog, era desempenhado pelo Hélio Musk, que não possuía conhecimento técnico necessário e nem o conhecimento do problema sendo resolvido. Para ele, se tratava apenas de funcionalidades a serem implementadas para ter um produto funcionando o mais rápido possível.”

Para obtermos mais explicações, mostramos a documentação para o grupo de docentes da UFPR e eles confirmaram a existência de problemas sérios no processo de desenvolvimento da Vina Systems.

O Professor Roberto Pereira, da área de Interação Humano-Computador, destacou que é na formação desse backlog inicial que está o ponto chave para o sucesso de uma solução. “Seja qual for o modelo de processo de desenvolvimento de software adotado, o entendimento do problema é a etapa mais crítica. E, por quê? Basicamente porque qualquer problema que não seja antecipado nesta etapa inicial, qualquer mal entendido, qualquer ambiguidade ou falta de informação, será propagado para todo o restante do processo até a solução final. Começar a definir uma solução sem ter entendido efetivamente o problema que ela deve resolver é igual a projetar um prédio sem nem saber o local onde ele será construído e quais recursos e restrições precisam ser considerados.”

O Professor ainda chamou a atenção para a falta de envolvimento de especialistas do domínio, como profissionais da área da saúde. “Em um projeto desafiador e claramente multidisciplinar, é preciso envolver as partes interessadas! Isso significa ter equipes que contemplem as diferentes áreas envolvidas, da computação à saúde, por exemplo, mas que incluam outras partes importantes, como representantes do público-alvo e da sociedade civil. Há diversas técnicas, como as do Design Participativo, e há princípios, como os do Design Universal, que ajudam a conduzir atividades de entendimento do problema com equipes diversas. Esse entendimento crítico do problema é essencial para se projetar uma solução que efetivamente resolva o que precisa resolver, e que faça sentido às partes interessadas.”

A Professora Silvia Vergilio, doutora e especialista em Engenharia de Software na UFPR, comentou que Histórias de Usuário são adequadas para atividades de brainstorming, para levantar requisitos, mas que seu propósito não é especificar esses requisitos em detalhes. “Se uma História diz ‘Eu, como usuário, quero que o sistema monitore meus níveis de estresse e ative o sistema de relaxamento quando o estresse estiver alto’, ela está apenas dizendo o que precisa ser feito, não como precisa ser feito. Se não há uma especificação detalhando isso, então a equipe de desenvolvimento não tem parâmetros para saber se está ou não de acordo com o que se espera, e aí o espaço para problemas é abundante.”

A Professora ainda teceu mais observações:

“Pela documentação recebida, o backlog do produto era definido apenas no início do processo, por uma equipe restrita, potencialmente enviesada, e não voltava a ser atualizado. Do modo como foi configurado, o processo da Vina Systems parece jogar fora uma das principais vantagens dos métodos ágeis, que é a capacidade de responder às mudanças, e despreza especificações mais detalhadas que são necessárias para apoiar o desenvolvimento do produto.”

Segundo nossa fonte, a Scrum Master Eliza Ventura desabafou várias vezes com a equipe sobre a dificuldade de entender as demandas e priorizações feitas pelo Product Owner. “Na equipe, o backlog era chamado de ‘lista de desejos’, porque ninguém sabia muito bem o que é que o pessoal que criou o backlog tinha em mente. Algumas coisas pareciam uma viagem. Quando fazíamos a reunião de planejamento do sprint com as atividades a serem executadas é que tirávamos as dúvidas e tomávamos as decisões. Se alguma dúvida surgisse, a gente já debatia e decidia ali mesmo, na hora, com a equipe de devs.”

A SBC Horizontes questionou a fonte se esse processo não abria muitos problemas para a equipe, e não poderia favorecer situações como aquela identificada no código desenvolvido pelo programador Malcom Pila. “Certamente pode. No desenvolvimento você não tem tempo de ficar indo atrás de especificações. Você vê o que precisa fazer e faz. É possível sim que o Malcom tenha implementado o sistema achando que estava fazendo o trabalho correto. Mas o problema foi bem grosseiro, então é difícil ignorar o descaso com a qualidade do código.”

A fonte ainda comentou haver preocupação sobre possíveis interferências “não identificáveis” no projeto. “Nós sempre comentávamos que era fácil alguém introduzir problemas no código intencionalmente, ou até mesmo um requisito no backlog, porque não tem muito controle sobre quem definiu o quê e porquê. Em equipes pequenas, ok, mas em equipes grandes como a nossa, isso é muito complicado.”

Pouco antes da publicação desta reportagem, a SBC Horizontes recebeu resposta por escrito do advogado do programador Malcom Pila. A nota dizia que o código sendo apontado como causa do problema não foi escrito pelo programador, e que a defesa está solicitando uma auditoria do controle de versões do código para identificar a origem das mudanças.

^{Jade Scobri,}^{Jornalista Científica}
^{Especialista em Tecnologias Computacionais}

Acessos: 336