Windows Azure Cloud Computing

Para quem não sabe, Windows Azure é a plataforma de Cloud Computing da Microsoft. Recentemente eu tive oportunidade de participar de uma apresentação do Rafael Godinho, especialista de desenvolvimento da Microsoft, e gostaria de compartilhar as informações que obtive.

Para que serve a Cloud afinal?
A plataforma é oferecida para atender, principalmente, requisitos de escalabilidade massiva de aplicações (de poucos a milhões de acesso). Ela evita que uma empresa precise alocar recursos de hardware desnecessários. Também evita que uma necessidade súbita de acessos não seja atendida por falta de hardware. Isso é obtido por intermédio de um balanceador de carga que gerencia a execução de uma ou mais máquinas virtuais conforme as necessidades forem surgindo.

Do que é composto?
O Azure é composto basicamente por tecnologias Web. É dividido em dois tipos de máquinas virtuais, Web e Worker. A Web contém basicamente um Windows Server 2008/R2, IIS7, ou 7.5, ASP.NET 3.5 ou 4.0 e FastCGI para PHP e outras linguagens de script. Já o Worker é muito semelhante ao serviço de background do windows, para processamento assíncrono, geralmente sem User Interface.

As empresas estão usando Azure?
O palestrante comentou sobre a produção do filme avatar, que usou instancias de máquinas do tipo Worker para reduzir o processamento das cenas de dias para minutos, possibilitando uma regravação das cenas que não ficam boas no mesmo dia. Há casos também nos quais a empresa acaba reduzindo em até 40% os custos com infraestrutura, liberando os profissionais para trabalhar mais próximos às questões de negócios.

Porque é divertido programar?

Em primeiro lugar vem a satisfação de construir algo que você mesmo projeta. Em segundo, é a sensação que você tem de construir coisas úteis para os outros. Em terceiro vem o fascínio de objetos complexos. Em quarto, a aprendizagem constante de natureza não repetitiva. Finalmente, a delícia de trabalhar em um meio tão maleável, levemente deslocado do pensamento puro e tão capaz de produzir grandes estruturas conceituais.

Contudo, a execução deve ser perfeita. Nesse aspecto o computador se assemelha às mágicas das lendas. Se uma letra ou uma pausa do encanto não estão rigorosamente no formato apropriado, a mágica não dá certo. Seres humanos não estão acostumados a serem perfeitos, e poucas áreas da atividade humana exigem isso. O ajuste ao requisito da perfeição é, penso eu, a parte mais difícil de aprender a programar.

- Síntese de uma reflexão de Brooks em seu livro “O Mítico Homem-Mês” – Ed. Campus

O que é Experiência do Usuário?

Muitas vezes considerada como uma novidade, a Experiência do Usuário (UX – User Experience) nada mais é do que “a percepção que um cliente têm em relação a um produto”. Junto com o SEO (Search Engine Optimation), ela é extremamente importante nos trabalhos atuais, já que existe grande quantidade de oferta de serviços na web. Um dos objetivos primordiais da UX é absorver a complexidade para dentro do sistema, sem refleti-la para o usuário.

A disciplina de UX é composta por algumas disciplinas já bem conhecidas e seus respectivos entregáveis: design de interface, arquitetura da informação, usabilidade, design de produto e outras atividades relacionadas com a apresentação, interação e organização de serviços online. Ela procura responder questões como: O produto pode ser facilmente encontrado? Quando encontrado, é fácil entender o que é e como utilizá-lo? E quanto ao funcionamento, é desejável e atraente?

Algumas técnicas são utilizadas para testar a eficiência de uma experiência – se passar pelo usuário, assistir um usuário real utilizando o serviço ou desenvolver algoritmos que entreguem informações sobre a utilização da aplicação.

Como aplicar em cinco passos

Não existe uma receita mágica em como aplicar a UX na prática em um projeto, mas um passo a passo básico pode ser seguido para servir como orientação inicial:

1. Eleger os objetivos da aplicação e definir estratégias sólidas para atingi-los.
2. Entender o domínio do problema, as necessidades dos usuários e a concorrência.
3. Priorizar o conteúdo e as funções necessárias.
4. Aplicar a Arquitetura de Informação, Mapa do Site, Fluxo do Usuário, etc.
5. Se possível, testar partes da aplicação com usuários reais.

Para assistir um projeto de UX público, veja o link d7ux.org

Estimativas de Software realmente funcionam?

Se você desenvolve software provavelmente já esbarrou nessa questão alguma vez. Já li e ouvi muitas pessoas reclamando da utilidade das técnicas existentes, dizendo que não basta utilizar apenas uma estimativa para se obter um prazo para desenvolvimento de software, ou pior, que não adianta estimar software pois a criação de programas de computador é uma atividade totalmente empírica, não mensurável.

Há quem acredite que as estimativas acabam incluindo muita gordura em um projeto. Outras que simplesmente não funcionam. Porém, Brooks em seu livro “O Mítico Homem-Mês” afirma que todo engenheiro de software tem a tendência de ser otimista demais com relação a prazos utilizando apenas o feeling, porque o engenheiro não costuma enxergar as complexidades de uma implementação em um primeiro momento. O resultado disso são prazos infundados que acabam por se mostrar extremamente sensíveis.

Uma estimativa serve para estimar, e não para estabelecer um contrato. Porém, o mercado exige escopo, custo e prazo na prestação de serviço. Algumas questões surgem – O que vai ser feito, quanto tempo você vai precisar, quanto isso vai custar? – e nada mais natural para o prestador de serviços que utilizar-se de uma ferramenta para estimar um determinado trabalho que será realizado. Todos os clientes querem um prazo, todas as atividades necessitam de alguma espécie de estimativa e todas as partes, sem exceção, conquistam algum sucesso ou fracasso nesse caminho. Seja na construção de uma casa, de um forno petroquímico ou da linha de produção uma cadeira. Acho muito difícil ser diferente com desenvolvimento de software porque o mundo simplesmente não funciona de outra forma.

Atualmente estou experimentando algumas técnicas de estimativas de desenvolvimento de software. A primeira delas, Análise de Pontos de Função, considera funções do software, arquivos lógicos internos e transações para estabelecer o tamanho funcional do software. Com base nesse tamanho, e dadas algumas variáveis do ambiente humano e técnico no qual o trabalho se desenvolverá, é possível obter uma estimativa. Ela foi criada em 1977 por Alan Albrecht na IBM, e hoje é uma unidade de medida reconhecida pela ISO.

A segunda, Pontos de Caso de Uso, tem mais aderência com a Análise Orientada a Objetos e presume a utilização de um diagrama UML chamado Diagrama de Casos de Uso para mapeamento de funcionalidades do software. Essa técnica também utiliza variáveis do ambiente humano e técnico envolvido com o projeto para se obter uma estimativa final.

Eu particularmente fiquei mais empolgado com o Pontos de Caso de Uso pela possibilidade de utilizá-lo logo no início do projeto, obtendo uma estimativa sem ter que detalhar demais as funcionalidades de um software prematuramente, antes do cliente fechar o contrato. Estou empregando essa técnica em um projeto de Software de Gestão da Qualidade, e estou obtendo bons resultados.

Princípios do Engenheiro de Software

Conheci recentemente o site do Software Engineering Ethics Research Institute. Nele há um código de ética e prática profissional  produzido por uma força-tarefa da ACM e IEEE. Segue o resumo, mas vale a pena dar uma conferida no original.

1. Público
Engenheiros de software devem agir consistentemente com o interesse público.

2. Cliente e Empregador
Engenheiros de software devem agir de um modo que seja do melhor interesse de seus clientes e empregadores e consistente com o interesse público.

3. Produto
Engenheiros de software devem garantir que seus produtos e modificações relacionadas atendam às melhores normas profissionais possíveis.

4. Julgamento
Engenheiros de software devem manter integridade e independência em seu julgamento profissional.

5. Gestão
Gerentes e líderes de engenharia de software devem subscrever e promover uma abordagem ética à gestão do desenvolvimento e manutenção de software.

6. Profissão
Engenheiros de software devem avançar na integridade e reputação da profissão, de forma consistente com o interesse público.

7. Colegas
Engenheiros de software devem ser justos e colaborar com seus colegas.

8. Individual
Engenheiros de software devem participar de aprendizado vitalício com respeito à prática da sua profissão e promover uma abordagem ética da prática profissional.

[Editado em 30/01/2012]
Mais Links a respeito de Código de Ética e Conduta
http://www.acm.org/about/se-code
http://www.acm.org/about/code-of-ethics

Overview sobre Scrum

O que é Scrum?
Scrum é um framework para desenvolvimento ágil e gerenciamento de projetos. Ele é baseado em ciclos de 2 a 4 semanas chamados Sprints, onde se trabalha para alcançar objetivos bem definidos. Estes objetivos são representados no Product Backlog, uma lista de itens que o cliente deseja que sejam feitas. Esta lista é constantemente atualizada e repriorizada.

Quais são os papéis?

Equipe/Time: responsável por entregar soluções, geralmente é formada por um grupo pequeno (entre 5 e 9 pessoas) e que trabalha de forma auto-gerenciada;

Product Owner: responsável pela visão de negócios do projeto, é ele quem define e prioriza o Product Backlog. Geralmente é o papel representado pelo cliente;

Scrum Master: é uma mistura de gerente, facilitador e mediador. Seu papel é remover obstáculos da equipe e assegurar que as práticas de Scrum estão sendo executadas com eficiência.

Como funciona?

Definição do Backlog: todas as funcionalidades ou mudanças no produto são definidas pelo Product Owner no Product Backlog. Esta lista é prioriza para refletir as necessidades dos clientes ou demandas do mercado. Os itens do topo da lista são destacados para serem entregues no final do próximo Sprint.

Andamento do Sprint: durante o Sprint, os itens do Product Backlog que devem ser entregues são agora tratados no Sprint Backlog. As tarefas são agora responsabilidade da equipe, que tem autonomia para decidir como elas devem ser executadas.

Reuniões Diárias: o Scrum Master se reune diariamente com a equipe num mesmo horário, para que se reporte: O que foi feito ontem? O que se pretende fazer hoje? Quais são os impedimentos que estão atrapalhando a execução das tarefas?

Revisões: no final do Sprint a equipe demonstra os resultados para o Product Owner e demais interessados, de forma que os itens do Backlog sejam considerados prontos e então possa se iniciar um novo Sprint.

Metodologia de Teste TDD

Implica em desenvolver o teste inicialmente, e em seguida é produzido código apenas para passar no teste.

Refatoração
Significa melhorar um código já existente eliminando as partes redundantes ou duplicadas, alterando a estrutura do código sem alterar o comportamento do componente ou sistema.

Benefícios do TDD

Permite desenvolvimento simples de incrementos
Envolve um processo de desenvolvimento mais simples
Provê um constante teste de regressão
Melhora a comunicação
Melhora o entendimento do comportamento do sistema
Centraliza o conhecimento

Passos do TDD

1) Escrever um teste que define um comportamento
2) Escrever o código fonte que funcione frente ao teste escrito
3) Refatorar. O teste garante que a refatoração não corromperá o código.

Métricas de Teste

Seguem algumas métricas utilizadas nos Testes de Software

Falta de coesão dos métodos
Porcentagem de public e protected
Acesso publico a Data Members
Número de classes raiz
Número de classes filhas

Tipos de Teste

Teste de Unidade
Testa a Classe individualmente. Teste dos métodos no contexto dos objetos, usa Class Diagram.

Teste de Integração
Testa o relacionamento entre as classes.

Teste de aproximação baseado em thread
Utiliza Sequence Diagram e/ou Collaboration Diagram. Deve-se seguir a ordem de execução da interação entre os objetos.

Teste de aproximação baseado em uso
O objetivo é testar inicialmente as classes independentes e em seguida as classes dependentes.

Teste de regressão
Testa as partes do sistema afetadas por uma correção de erro para que não ocorram produção de novos erros.

Teste de Sistema
Testa os requisitos funcionais do sistema como um todo. A montagem dos cenários de teste é realizada através dos Casos de Uso.

Performance
Estresse
Segurança
Recuperação

Teste de Validação
O foco dos testes são os requisitos do sistema. Existe o teste Alpha, realizado no ambiente de desenvolvimento, e o teste Beta, realizado no ambiente do usuário.

Estratégias de Teste

Caixa Branca

Teste básico do trajeto
Considera um fluxograma. Testa todos os caminhos.

Teste de Estrutura de controle
Considera condições e repetições

Caixa Preta

Teste baseado em gráficos
Considera diagrama de colaboração. São testadas as interfaces entre os objetos.

Teste de equivalência
Testa entradas válidas e inválidas por comprimento, valor, etc

Teste de limite de valor
Teste de valores mínimos, máximos, abaixo do mínimo e acima do máximo.