Analista de Requisitos x Usuário

Diagrama de Classes - O que é?

Reproduzo excelente artigo sobre o uso de diagramas de classes (UML). Extremamente didático e muito importante para quem desenvolve software. Veja o artigo completo AQUI

Deve o Arquiteto de Software escrever código?

Este post é bastante interessante. Discute uma questão permanente no desenvolvimento de software: Deve o Arquiteto de Software programar (escrever código)? Leia   AQUI e dê a sua opinião

O grande problema no desenvolvimento de software é linguístico

Este post é uma pancada na cabeça de quem desenvolve software e outra na de quem contrata desenvolvimento de software. É para ser lido com muita atenção antes de se tirar alguma conclusão. Leia aqui.

As Transformações da Indústria de Software

Raul MiyazakiDiretor | OraclePublicado Originalmente em Endeavor News

Maior alcance, velocidade e controle de qualidade garantem o impacto positivo do “Software as a Service” (SaaS) para os empreendedores.

Na nova era do “cloud computing” (computação em nuvem), o “Software as a Service” ou SaaS é uma modalidade radicalmente diferente de vender e usar softwares. Em uma analogia com o sistema de energia elétrica, em que usinas e centrais elétricas geram a energia que será consumida em cada casa ao simplesmente ligar os aparelhos em tomadas, no modelo “Software as a Service”, o cliente final precisa apenas conectar seus dispositivos (PC, tablet, smartphone) à Internet para usar aplicativos instalados em um DataCenter, onde os dados e programas são geridos profissionalmente de forma centralizada, incluindo as questões de versão, update e correções. Como já está tudo pronto, o tempo de projeto é muito menor, comparado ao modelo tradicional. E, melhor ainda, pagando tudo como um serviço mensal, em vez de fazer grandes investimentos upfront.

No modelo tradicional, uma empresa desenvolve o seu produto, vende uma licença de uso e entrega CDs para a instalação. O cliente precisa comprar hardware, instalá-lo numa infraestrutura especializada, ligá-lo na rede da empresa e instalar o software (no caso de um software básico ou de plataforma, como banco de dados ou middleware). No caso de um pacote aplicativo de negócio, vai ter quer comprar também serviços para customização e implementação.

Já com o sistema em produção, o cliente deverá instalar updates de atualização (para corrigir erros e eliminar brechas de segurança, por exemplo), que fazem parte do contrato de manutenção. Quando uma nova versão for lançada, precisará de um novo projeto, não somente para migrar todo o sistema, mas para fazer upgrade de hardware, equivalendo-se ao nível de sistema operacional da nova versão.

Tipicamente, o Software as a Service (SaaS) é um modelo ideal para pequenas empresas, que não precisam ter a sua área de tecnologia da informação, mas também se aplica a grandes e médiasempresas, para projetos departamentais nos quais a necessidade de negócio exige uma velocidade maior de implantação inicial. Além disso, após o primeiro ano de operação em regime de produção, é possível transferir o projeto para dentro da área de TI da empresa.

Para o empreendedor da área de software, o impacto é muito positivo. Ganha-se alcance, pois o produto fica disponível pela Internet. A velocidade de adoção é muito maior, uma vez que o investimento upfront é substituído por um serviço mensal, além de eliminar a fase de investimentos em hardware e infraestrutura. O controle da qualidade do produto é imediato, pois não depende do cliente instalar as correções, tudo é feito de maneira centralizada de forma que a última versão esteja disponível para os clientes simultaneamente.

Permanecem, no entanto, alguns pontos de atenção, que não se alteram para o modelo SaaS: desenvolver o software usando padrões abertos de mercado garantem que o cliente possa integrá-lo com outras aplicações; capacitar uma rede de implementadores; e preparar a força de vendas para identificar os benefícios para o negócio do cliente, pois o software não se vende sozinho pela Internet.

Raul Miyazaki é Diretor de Contas Estratégicas de Financial Services da Oracle do Brasil.

Refactoring: torne seu código mais simples, organizado e legível

Refactoring ou refatoração é um processo que tem como principal objetivo tornar o código mais legível e com maior facilidade de manutenção. Menciona-se processo, pois refactoring não consiste em apenas alterar o código que já funciona, pois quando há qualquer tipo de alteração, há riscos de introdução de novos bugs.

Segundo o relatório de maio de 2002 do National Institute of Standards and Technology, o custo de um bug em fase de desenvolvimento é de uma 1 unidade (entenda unidade como qualquer custo, como por exemplo hora/pessoa, dólares, etc...) e após ir para produção esse mesmo bug pode custar até milhares de dólares. Por isso, a refatoração de código, quando implantada desde o inicio do projeto, terá um custo muito menor.

Além do beneficio de redução de custos, a refatoração, como tarefa diária de desenvolvimento, ajuda a manter a equipe mais cuidadosa com o código desenvolvido, pois se um código parece estranho ele logo será corrigido, corrigindo um possível problema o mais cedo possível.

Refactoring é algo maior, que envolve pequenos passos, testes, disciplina e força de vontade. Refactoring é importante quando o desenvolvedor tiver que adicionar alguma característica ao programa, e, o código não estiver estruturado para receber esta característica. Então, primeiro é aplicado o refactoring no código e depois é adicionada tal característica. É importante certificar de que tenha um bom conjunto de teste antes de fazer o refactoring.

No TDD, ou Test-Driven Development, que é uma das práticas do XP (Extreme Programming), a ideia é que primeiro sejam desenvolvidos os testes para só então escrever o código necessário para que o teste passe. Com os testes devidamente criados, temos a segurança necessária para então refatorar o código e garantir que os mesmos não quebrarão nenhuma funcionalidade.

No TDD, temos os seguintes passos: 
- Criar um teste. 
- Escrever o código 
- Executar o teste - ele não passará 
- Reescrever o código para o teste passar. 
- Rodar novamente o teste. Ele passará. 
- Refatorar o código. 
- Repetir quantas vezes forem necessárias, até você atingir o resultado desejado. 

Três características gerais identificadas nos refactorings são: 
- Estes podem ser completamente automatizadas por ferramentas de refactoring. 
- Quando um refactoring é corretamente aplicado, este não introduz novos erros ao sistema. 
- Refactorings mais complexos podem ser criados pela composição de outros. 
- Se cada refactoring primitivo preserva o comportamento do sistema, a composição destes também irá preservar. 

Refactoring tem como propósito melhorar a estrutura do código de forma a fazer um programa mais reusável e fácil de ser entendido, sendo então um aspecto importante para evolução de softwares reusáveis e frameworks. Uma característica importante é que, como o refactoring preserva o comportamento observável, se houver erros semânticos no código original, também haverá erros no código reestruturado.

Desenvolvimento Orientado a Testes

Há algum tempo, temos investido na qualidade do desenvolvimento de software. Para nós, um dos principais pilares de sustentação da qualidade são os testes. Reforçando a diretriz e foco, adotamos o TDD (Test Driven Development), que prega o desenvolvimento orientado aos testes desde a concepção do componente/classe/rotina...