Building Minds - o Blog da OnCast

A OnCast finalmente rende-se a uma forma intuitiva de gestão. Fases em cascata é realmente a melhor solução para atendar às demandas do mercado, tanto emergenciais, quanto grandes projetos que, por terem uma extensa fase de planejamento, conseguem segui-lo à risca.

Nossos projetos agora terão um Gerente de Projeto, que irá centralizar a informação e as decisões. O GP irá delegar ao seu critério para seus subordinados. Caso haja algum problema ou descontentamento, os recursos serão ser trocados imediatamente, a fim de preservar o plano do projeto. O Gerente de Projeto irá comandar as alocações e desalocações de pessoal, com seu WBS e gantt chart, além da geração de artefatos, para todo o fluxo descrito a seguir:

• No início do projeto, com tudo formalizado em contrato, para segurança de todas as partes e definição clara de interfaces cliente/fornecedor, analistas de requisitos irão documentar claramente as necessidades do cliente.
• Em seguida, o analistas de sistemas, assessorados por arquitetos de sistemas, transformarão a visão de requisitos em uma visão de sistema. Tudo muito intuitivo!
• Um arquiteto da informação poderá colaborar com a documentação dos requisitos e entregar macro esquemas de tela junto com os artefatos do analista de sistemas.
• Os designers criarão todas as telas, para que tudo fique claro antes da mera programação.
• Os programadores poderão dividir responsabilidades, preferencialmente por módulos dos sistema. Assim ele será conhecedor do todo seu módulo, de fácil controle. Ferramentas case e proprietárias são priorizadas neste momentos, por sua agilidade e suporte.
• Agora só falta testar! Inicia-se a fase de verificação, quando planos de testes confrontam o resultado da programação e se por acaso algum erro for encontrado, é fácil localizá-lo dada a vasta documentação do projeto e às ferramentas de debug. Neste momento, todos os módulos programados são integrados. A equipe de testes deve ser muito pragmática e apaixonada por trabalho repetitivo e braçal em teclado.
• Em paralelo aos testes, com documentação farta do projeto, o produto começa a ser documentado.
• Por fim, e ainda intuitivamente, o software segue para homologação e produção.
• Após em produção, o sistema começa a sofrer manutenções que começam a torná-lo, muito aos poucos, usável.

O que antes era um tripé incerto na gestão de projetos, Tempo, Escopo e Custo, agora mantém-se fixo e a variável que soluciona a equação é a Qualidade:

• Prazo é impossível alterar, já que o projeto inicia com seu fim anunciado à diretoria, à imprensa e ao mercado.
• Redução do Escopo impossibilita um grande evento de lançamento, pois obviamente é feio o sistema estar incompleto, mesmo que a maioria das funcionalidades não sejam utilizadas nos primeiros meses.
• Quanto ao Custo, nem se fala: quanto menor o investimento, maior o ROI. Não há o que argumentar, pois é pura matemática!
• Já a Qualidade, dá-se um jeito! Boas práticas atrapalham o mundo real. Nem sempre é preciso 3 camadas, desacoplamento e automatização de build e testes. Depois da entrega isto pode ser visto… Em um projeto futuro…

A OnCast, que até agora estava melhorando continuamente, finalmente atinge um ponto de maturidade, finalizando o ciclo de aprendizado. Com a adoção do OnCascade, espero em breve poder dar más notícias…

Adriano Campestrini Metodologia, Riscos

Muitas vezes temos a necessidade de executar um mesmo teste repetidas vezes mudando apenas alguns parâmetros. A solução mais simples caso sejam poucos testes é replicar o método de testes e mudar as variáveis, ou então criar um método com as asserções desejadas e chamá-lo com os diferentes parâmetros.

Ambas as possibilidades apresentadas pecam, pois não respeitam o princípio DRY. Uma solução muito mais elegante é usar os testes parametrizados, uma possibilidade que para quem usa JUnit existe a partir da versão 4.

O funcionamento é simples: um método no teste, anotado com Parameters, deve retornar uma coleção de arrays, que serão os parâmetros de execução:

@Parameters
public static Collection<Object[]> parameters() {
    List<Object[]> list = new ArrayList<Object[]>();
    list.add(new Object[] {"asshole!", "jerk!"});
    list.add(new Object[] {"what the hell?", "what the heck?"});
    return list;
}

Cada array desta coleção fornecerá os argumentos para o construtor do teste, possibilitando assim que estes valores sejam salvos em campos da classe, e utilizados por quem precisar dos mesmos:

public ProfanityFilterTest(String input, String output) {
    this.input = input;
    this.output = output;
    filter = new ProfanityFilter();
}

A classe de testes deve ser configurada para rodar com um runner específico, o Parameterized:

@RunWith(Parameterized.class)
public class ProfanityFilterTest {
[...]

Com estes passos básicos, ao rodar a classe testes, cada teste será chamado uma vez com os parâmetros fornecidos.

Para conferir o código completo baixe ProfanityFilter.java e ProfanityFilterTest.java.

Renato Besen Arquitetura de Software, Auto-gestão