segunda-feira, 15 de abril de 2013

Requisitos tóxicos - a responsabilidade é do time de TI

Referência: www.pc1news.com
Os requisitos tóxicos (toxic requirements) são requisitos captados na fase de desenho de um produto de software que comprometerão posteriormente o funcionamento correto do software. O comprometimento pode ser parcial, como uma degradação na performance de uso, ou total, impendido que o software cumpra o seu objetivo.

O exemplo clássico é o bug do ano 2000. Uma definição de armazenar datas com apenas duas posições para o ano, que parecia lógica e bastante razoável até o final dos anos 1980, era, na verdade, um requisito tóxico esperando para dar problema na virada do milênio.

Recentemente fui confrontado com uma situação onde o requisito era a transmissão de imagens em tempo real em um software que seria usado remoto sobre uma infraestrutura extremamente limitada. Esse seria um requisito tóxico em potencial, mas fomos capazes de convencer o cliente da limitação e o requisito não foi incluído. Neste exemplo havia uma boa relação de confiança entre o time técnico e o time de negócios, o que facilitou a discussão, mas, e quando isso não acontece?

Todos nós temos exemplos de requisitos tóxicos que não foram apontados. Seja por falta de força política do time técnico, seja por questões comerciais. E todos já vimos como essa história termina.

A responsabilidade de apontar e remover o requisito tóxico é do time técnico: do gerente do projeto, analista de requisitos, engenheiro de software, etc, e deve ser levada adiante por mais antipática que pareça aos olhos do cliente final. A alternativa é muito pior: seguir todo o projeto e entregar um software ao final que funciona parcialmente ou não funciona. Situação que termina em sérios problemas de desconfiança entre empresas e times, desentendimentos comerciais e, não raro, litígios.

segunda-feira, 21 de janeiro de 2013

Por que as empresas de engenharia de software não contratam apenas desenvolvedores de garagem?

Referência: Dilbert.com

A metáfora do desenvolvedor de garagem pode ser muito mais norte americana do que brasileira ou de outros países, mas a pergunta é válida e nós todos já a ouvimos de formas diferentes no início de projetos de tecnologia da informação:
- Por que vocês, que são profissionais de informática, vão levar 8 meses pra desenvolver esse sisteminha? Eu faço isso em um mês com excel aqui na minha área mesmo?
- Vai custar tudo isso? Com meu excel seria de graça...
Ou a minha forma preferida desta pergunta:
- Oito meses? Meu filho disse que faz isso pra mim em poucas semanas...
Todas estas perguntas são variações da pergunta: por que as empresas de tecnologia não mandam embora todos os seus engenheiros de software, analistas de sistemas, gerentes de projetos, etc, e contratam dois ou três adolescentes trabalhando em casa?

No livro The Mythical Man-Month, Frederick Brooks propõe uma resposta interessante a esta pergunta. O livro reuni uma série de ensaios sobre engenharia de software desenvolvidos ao longo da vida em corporações (ele foi o gerente do projeto do IBM System/360) e acadêmica. Vários dos ensaios são bem interessantes, sendo o melhor o que dá nome ao livro, mas alguns são bem datados e só servem como curiosidade histórica.

O que o Brooks argumenta sobre a questão deste post é que o desenvolvedor de garagem constrói o programa, ainda que bem feito e testado pelo próprio desenvolvedor (teste unitário), enquanto a engenharia de software entrega um produto de sistema, que deve incluir, além do programa inicial:
  • O código deve ser generalizável e manutenível;
  • Os testes devem ser, além do inicial, o integrado, o de aceitação pelo usuário e o de regressão (no mínimo, além de outros quando aplicáveis), com os scripts e evidências de execução e sucesso;
  • Documentação completa e "viva" tanto para o usuário final quanto para a equipe técnica; e
  • As interfaces devem estar construídas, testadas e documentadas.
Todas estas atividades e produtos elevarão, tipicamente (número do Brooks) em nove vezes o tempo e custo do programa desenvolvido originalmente, mas deverão trazer uma contraparte em qualidade.

Achei a resposta do Brooks interessante, mas nos leva a pensar se temos entregado todos estes produtos de forma clara e com qualidade, para que o cliente consiga ver o que compõe o tempo e o custo a mais.

domingo, 1 de julho de 2012

Qualidade de software: importância da revisão de requisitos e de código


A dificuldade na obtenção dos requisitos. Referência: Dilbert.com

A fase de desenho em um projeto de engenharia de software é quando os requisitos iniciais do cliente - que é, ou representa, o futuro usuário do software - se transformam no modelo detalhado do que será construído, testado, implantado e suportado nas etapas seguintes do ciclo de vida de uma solução de software.

Os engenheiros de software sabem que uma fase de desenho bem sucedida é determinante para um bom resultado do projeto, para uma quantidade pequena de mudanças nos requisitos e, posteriormente, no código construído ou reusado (pois pode garantir, neste caso, que o código reutilizado atende, de fato, às necessidades do usuário).

Considerando como qualidade na fase de desenho a mínima quantidade possível de erros e mudanças no software que virá a ser construído, vamos explorar algumas estatísticas sobre quantidade de erros em projetos de software. É importante ressaltar que esse parâmetro, no entanto, é apenas uma faceta da qualidade de software, pois se percebe claramente que ele não tem influência na usabilidade da interface de um aplicativo, por exemplo, e a clareza na interface é um parâmetro essencial da qualidade percebida pelo usuário.


Conforme estatísticas do mercado norte americano de desenvolvimento de software, para cada ponto de função construído, encontraremos, tipicamente, 5 erros. No momento que este aplicativo for disponibilizado para uso, em torno de 3% destes erros ainda estarão presentes (97% de eficiência na remoção dos erros) se forem empregadas técnicas de revisão de requisitos, revisão de código e análise estática (static program analysis). Se estas técnicas não forem empregadas, em torno de 15% dos erros no código ainda estarão presentes no software (85% de eficiência na remoção dos erros).


Para exemplificar, um software de 2.000 pontos de função, que seria um aplicativo de porte médio, terá, no mínimo, 300 erros no seu código (eficiência de 97% na retirada dos erros gerados), podendo chegar a 1.500 (eficiência de 85% na remoção dos erros).


Se considerarmos que em torno de 15% dos erros são críticos, teremos de 45 a 225 erros críticos no momento do início do uso do nosso software. Isso é muito. Entregamos aos nossos usuários, segundo esta estatística, em um software de porte médio, até 225 erros que o farão parar o seu processo de negócio e lhe trarão impacto financeiro de algum tipo.


Se refizermos as contas para um software grande (10.000 pontos de função) chegaremos a uma expectativa de encontrar entre 1.500 e 7.500 erros no momento da entrega do software, sendo de 225 a 1.125 erros críticos.


Fica bem evidente que perseguir a qualidade no processo da engenharia de software é um esforço primordial. A revisão dos requisitos capturados e do código desenvolvido se torna fundamental para que o projeto se aproxime do máximo de eficiência na remoção dos erros (97%), mas estas práticas não são, infelizmente, comuns no mercado de software hoje em dia. 


Uma alternativa é estabelecer uma revisão informal entre os analistas de requisitos e programadores envolvidos em um projeto, de forma que eles revisem mutuamente os requisitos e códigos uns dos outros. Com isso não será atingido o máximo de eficiência que a revisão formal permitiria (97%), mas será atingido mais que os 85% medianos.




Referência:

Software Engineering Best Practices by Capers Jones.

sexta-feira, 15 de junho de 2012

Engenharia de software, gurus e evangelizadores.

Estranha a nossa engenharia de software que tem gurus.

Sempre me chamou a atenção em eventos de tecnologia da informação o fato de que novas tecnologias são defendidas por gurus e evangelizadores.

Se um engenheiro civil desenvolve uma nova técnica para construir pontes, ele precisa apresentá-la para os seus pares com dados empíricos, estatísticas e pesquisas bem embasadas que comprovem a superioridade da nova técnica sobre as que estão em uso. Desta forma, ele pode convencer outros engenheiros a empregá-la. Não adianta que ele seja persuasivo, fale bem ou dê excelentes palestras. Os outros engenheiros não vão arriscar o uso de algo novo baseado nisso.

Na engenharia de software, no entanto, temos o título formal - e algumas empresas tem mesmo esses cargos em seus quadros - de guru, ou evangelizador, como alguém responsável por disseminar uma nova tecnologia. É comum irmos a palestras e um guru nos explicar porque o twitter ou o Facebook, por exemplo, vão revolucionar a forma de comunicação entre pessoas e sistemas dentro das corporações e porque eles devem ser incorporados de imediato ao dia a dia das empresas. Raramente, no entanto, nos é apresentado qualquer dado ou fato que comprove que esta mudança ocorrerá ou revolucionará para melhor os processos e negócios das corporações. Não tenho nada contra twitter e Facebook e a revolução que eles vêm causando fora das corporações. O meu ponto é: se queremos que a engenharia de software seja uma engenharia, precisamos suportar as nossa técnicas e tecnologias com dados empíricos.

Os gurus e evangelizadores são profundos conhecedores das novas tecnologias, metodologias e técnicas que apresentam, mas a metáfora voltada pra fé, e não fatos, acaba por depor contra a engenharia de software como uma verdadeira engenharia.

Sei da dificuldade de se obter dados empíricos e estatísticos sobre desenvolvimento de software, mas um bom começo no dia a dia do engenheiro de software seria usar as estatísticas do próprio profissional envolvido. Um gerente de projetos, por exemplo, pode se apresentar ao início de uma empreitada detalhando o seu portfólio: quantos projetos já tocou, quantos relacionados ao que ele está começando, qual sua taxa de sucesso e insucesso e o quê, com base em dados empíricos, ele percebeu que pode ser feito em um projeto para levá-lo ao sucesso ou reduzir ao máximo a possibilidade de problemas.

Se agirmos com este espírito, os nossos clientes se sentirão mais seguros e, um dia, a nossa disciplina pode deixar de ser vista com tanta desconfiança pelas corporações. Ou nunca aconteceu de você ser olhado de lado, no início de um projeto, por um cliente desconfiado que já tem uma lista de projetos de TI traumáticos no seu passado?

terça-feira, 5 de junho de 2012

A tecnologia é a culpada por falhas em projetos de tecnologia da informação?



Eu já fui responsável e já participei de diversos projetos de tecnologia da informação. Já fui responsável por integrações de sistemas via Internet, implantações de pacotes de mercado, construção de soluções de negócios desenvolvidas do zero e implantação de ERP. Uma discussão constante em projetos de informática é o quanto o uso de uma nova tecnologia, seja nova no mercado ou nova para o grupo que a está implementando, é a culpada por atrasos, aumento de custo ou cancelamento dos projetos.

Bom, resolvi analisar os projetos que já fui responsável, e alguns que participei, pra tentar perceber se há esta correlação entre usar novas tecnologias e o grau de insucesso dos projetos. Listei os projetos e apontei em quantos deles usei tecnologias novas de mercado, assim como em quantos deles usei tecnologias novas para o time de projetos. Usei como critério de sucesso se o projeto terminou próximo aos prazos e custos previstos e implementou o escopo previsto, ou se um aumento de prazo e custo estava atrelado a um aumento de escopo. Considerei insucesso, por sua vez, casos de aumento de prazo ou custo sem aumento de escopo (estouro de prazo e custos previstos), ou de cancelamento do projeto.

Daí consegui enxergar com clareza que, na minha amostragem, não há uma correlação direta entre o quanto a tecnologia é nova (para o time do projeto ou para o mercado como um todo) e o insucesso do projeto. Pelos critérios que estabeleci, encontrei aproximadamente 28% de projetos de insucesso que fui responsável ou participei - independente dos motivos - e em nenhum deles há uma tecnologia nova de mercado, assim como em apenas um deles há uma tecnologia nova para o time técnico. Olhando, por outro lado, os bem sucedidos, há as mais diversas combinações entre tecnologias novas de mercado e novas para o time de projetos.

Testei, então, um segundo fator que sempre considerei ter uma correlação direta com os projetos de insucesso: o quanto o time de projetos trabalhava bem junto (aqui considerado o "grande time", formado pelo time técnico somado ao time de clientes, usuários e usuários chave), ou seja: havia um bom relacionamento entre as pessoas e confiança entre as partes. Julguei os projetos um a um para classificá-los conforme me lembrava dos times e aqui fiquei surpreso: a correlação é absoluta. Onde o time funcionou bem, o projeto caiu nos meus critérios de bem sucedido. Onde o time não funcionou bem, o projeto caiu nos meus critérios de insucesso.

Essa correlação não deve ser uma surpresa para pessoas acostumadas com projetos de tecnologia, que, certamente, já a perceberam intuitivamente, mas o que me chamou atenção foi que, ao menos nos projetos que já toquei, a correlação é absoluta. Sempre que houve falha em ter um time bem formado, no sentido de que as pessoas trabalhem bem juntas, o projeto terminou com escopo incompleto, prazos e custos estourados, ou cancelado.

Sabemos que as tecnologias novas requerem uma curva de aprendizado e toda uma atenção deve ser dada a essa necessidade, mas a formação da equipe no começo de um projeto me parece ser fundamental para o sucesso no final. Os projetos de TI são, via de regra, bastante complexos e tendem a gerar conflitos pela grande quantidade de pessoas envolvidas, assim como a necessidade constante de decisões. A confiança mútua entre os membros da equipe e o bom relacionamento acabam, a meu ver, mitigando estes problemas potencias.

Um excelente livro sobre o assunto é o Peopleware, do DeMarco, que trata todas as facetas da formação de uma equipe além de analisar a importância que isto tem no final bem sucedido de um projeto de tecnologia da informação.