O que o RTC 3.0 pode fazer por você

Bruno Braga on November 29th, 2010

Para quem ainda não conhece, o IBM Rational Team Concert (RTC) é uma ferramenta para gestão do ambiente de desenvolvimento de forma colaborativa e pode ser usada tanto com desenvolvimento tradicional quanto com desenvolvimento ágil.

O que a ferramenta faz na prática é combinar recursos de gerencia de defeito (bug tracking) com gestão de mudanças, com planejamento e gerenciamento de projeto, com controle de versão (SCM) e com integração contínua – tudo isso em uma única solução sem necessidade de integrações, configurações complicadas e investimentos adicionais.

Além de um grande número de features, a simplicidade, usabilidade e performance foram as prioridades da IBM neste projeto comandado por Erich Gamma e lançado em 2008. Em 2010 foi eleito pela Forrester Research Inc em sua pesquisa “Agile Development Management Tools” como a melhor do mercado em número/qualidade das features (current offering). Segue abaixo uma cópia da pesquisa para consulta:

ftp://public.dhe.ibm.com/common/ssi/ecm/en/ral14023usen/RAL14023USEN.PDF

O detalhe é que a versão analisada pelo Forrester foi o RTC 2.0. Agora (dia 23/11) foi lançamento a versão 3.0 com muito mais features e diferenciais estrategicos e de negocio para os usuários. Segue abaixo um resumo das principais novidades:

  • Distribuição e Licenciamento:
    A forma de distribuição da ferramenta foi alterada. Agora não é mais necessário pagar pelo server. Ou seja: comprando 10 licenças de usuário você pode ter até 10 servers. Essa flexibilidade permite criar ambiente de treinamento, homologação e produção para o RTC sem custos adicionais.
  • Versão Gratuita com mais funcionalidades:
    Até o RTC 2.x a distribuição era dividida em Express-C, Express, Standard e Enterprise. Cada uma com um conjunto de funcionalidades diferentes. Na pratica o Express-C (versão gratuita até 10 usuários) era a versão mais simples e não possuia muitos recursos de customização por exemplo. Agora não existe mais versão de RTC Server e a lista de funcionalidades está associada ao tipo de licença de usuário ao invés do tipo de server. Com essa mudança os “Free Developers” tem acesso a maior parte das funcionalidades da ferramenta sem custo!
  • Gerenciamento de Projetos:
    Houve uma mudança de estrategia / escopo dos produtos e as principais features de gerenciamento de projetos formais (não-ageis) que estavam no RPC (Rational Project Conductor) foram incorporadas ao RTC. Com isso o RTC 3.0 possui gantt chart, dependencia entre tarefas, restrições, alocação de recursos, time tracking, gerenciamento de riscos entre outros recursos que já estavam presentes no RTC 2.x.
  • Nova Interface WEB:
    A interface WEB que já era excelente foi melhorada. Os pontos positivos foram mantidos mas foi adicionado mais flexibilidade em personalizações como menu customizável e gadgets OpenSocial. Além disso o carregamento via interface web ficou mais leve com melhoras notáveis nos planos do projeto.
    Essa reestruturação serviu também para implementar novos recursos na interface web que até então estavam disponíveis somente via interface Eclipse.
  • SCM Distribuído:
    Muitas empresas tem a necessidade de dividir o desenvolvimento de software com parceiros e fábricas externas. Com o SCM distribuído isso ficou mais fácil. Agora é possível armazenar os artefatos no SCM de um RTC local e depois sincronizá-lo com um RTC remoto.
  • Suporte ao Visual Studio Melhorado:
    Vários recursos avançados foram implementados para o Visual Studio que está mais alinhado com os recursos presentes no Eclipse. Outra melhora considerável é o suporte ao Visual Studio 2010.
  • Mais Integrações e Suporte ao Legado:
    A solução de integração do RTC 1.0 com ferramentas legadas era exclusivamente via connector que na prática é um duplicador de dados automatizado. Na versão 2.0 surgiu o brigde que estabelece um link entre dados do RTC e ferramentas externas sem a necessidade de duplicações. Na versão 3.0 as ferramentas passaram a utilizar melhor o bridge com links bidirecionais e a suporte a mais ferramentas legadas / versões.
    No Brasil grande parte dos clientes de ClearCase usam ClearCase Base ao invés do UCM e a integração com ClearCase Base agora é suportada. Além disso falando de produtos Rational, as integrações com Rational ClearQuest, Rational Synergy e Rational Change sofreram melhoras significativas.

O RTC faz parte do projeto Jazz (jazz.net) que é a plataforma de integração de ferramentas de desenvolvimento lançado junto com o RTC. Vale lembrar que este projeto seguiu o sucesso e experiencia da IBM no projeto Eclipse. Através do jazz.net você pode: interagir com a comunidade, deixar sugestões de melhorias, reportar defeitos, discutir com os desenvolvedores, baixar o código fonte e versões free, estudar a arquitetura do produto e o padrão aberto OSLC, acessar o roadmap das novas versões, enfim participar do desenvolvimento colaborativo da única plataforma ALM aberta do mercado.

Isso é um pouco do que o RTC pode fazer por você e sua equipe. Descubra mais em:
http://jazz.net/projects/rational-team-concert

Conheça e acesse este conteúdo também no blog da IBM Rational: http://bit.ly/dRDILC

Subscribe to this blog's RSS feed

Esse blog estava meio parado desde que comecei a viajar muito e ficar sem tempo. Mas vou postar aqui alguns tópicos que postei no blog da IBM Rational para começar a movimentá-lo novamente =)

O projeto Eclipse (eclipse.org) foi originalmente criado pela IBM em 2001 e tem desde então recebido cada vez mais apoio de empresas e comunidades de software livre.
Com o sucesso desse modelo de desenvolvimento envolvendo simultaneamente empresas e comunidade, em 2004 foi criada uma entidade independente chamada Eclipse Foundation. Essa entidade tem até hoje o objetivo de preservar a independencia do projeto Eclipse de desejos da empresa A ou B, dando voz a todos o envolvidos.
Os resultados são expressivos. Há algum tempo temos o Eclipse como base de ferramentas IBM e vários outros players, sem falar em projetos da comunidade.
Tudo isso tem feito o Eclipse evoluir muito rápido gerando beneficios para todos. Neste sentido, uma feature nova não é importante apenas para o software eclipse que baixamos do eclipse.org, ela gera valor para software livre e comercial e mais ainda para você usuário de alguma dessas ferramentas.

Já que o Eclipse é tão importante por ser a base de outros softwares, quais são suas tendências e o que está por vir para beneficiar nosso dia a dia?
Olhando o presente, o Eclipse 3.6 lançado recentemente provavelmente vai ser a utilizado em ferramentas Rational que serão lançadas em 2011. Essa versão possui uma série de pequenas melhorias em cima de uma base consolidada. Mas para falarmos de tendencias temos que olhar mais a frente.

Conhecendo o Eclipse e olhando para o futuro é fácil prever que: as ferramentas que serão lançadas em meados de 2012 e que talvez nem começaram a ser projetadas vão ter sua interface visual “repaginada” com um design similar a imagem abaixo.

Esse é um print do Eclipse 4 para “Early Adopters” que acaba de ser liberado. Basicamente essa é uma versão inicial do Eclipse 4 direcionada apenas para que desenvolvedores de plug-ins comecem a adaptar suas extensões para essa nova versão do Eclipse.

Ainda pensando em interface visual, este novo Eclipse vai suportar temas baseados em CSS, maior customização de widgets (campos e componentes visuais) e a tendencia é que cada aplicativo baseado nesta IDE tenha cada vez mais uma identidade visual diferenciada. Em alguns casos a primeira vista possivelmente nem vamos perceber que o software que iremos utilizar tem por trás uma solução tão madura e cada vez mais customizável.

Por falar em Eclipse, não foi atoa que seu modelo de desenvolvimento foi escolhido pela IBM para ser a base de outro projeto – http://www.jazz.net onde encontramos o Rational Team Concert, Rational Quality Manager, Rational Requirements Composer, entre outros que tem seguido o mesmo caminho de sucesso.

link original: http://bit.ly/go5qIB

SPIDER on Rails no Demoiselle (projeto do governo)

Bruno Braga on February 2nd, 2010

Uma boa notícia: o Demoiselle – framework do governo (SERPRO) para desenvolvimento Java avaliou e divulgou em seu blog um post sobre a ferramenta SPIDER on Rails:

http://sourceforge.net/apps/wordpress/demoiselle/2010/01/26/spider-on-rails-gerando-codigo-demoiselle/

O resultado da analise detalhada (ver link acima) e criação de um template para o Demoiselle foram bastante positivos e podemos destacar alguns trechos dessa analise:

“Continuando minha busca por alternativas legais para geração automática de código usando templates encontrei na InfoQ o interessantíssimo projeto open source SPIDER On Rails, um plug-in Eclipse bastante customizável que possibilita a criação de aplicações completas em várias linguagens”

“A geração automática de código costuma ser bastante criticada pela impossibilidade em se controlar a qualidade do que é produzido. O SPIDER permite uma grande flexibilidade para que deixemos o código do “nosso jeito” ou do “jeito da nossa organização”.”

“Vale destacar aqui uma funcionalidade muito interessante do SPIDER. O uso de incrementos com base em Expressões Regulares, permite incluir um pequeno trecho de código (incremento) em arquivos já existes sem perder configurações e/ou customizações do desenvolvedor realizadas anteriormente. Isso permite, por exemplo, alterar conteúdo de classes, páginas e arquivos de propriedades, a cada geração de um novo CRUD” (sem perder nada).

Mitos sobre geração de código

Bruno Braga on December 24th, 2009

Segue abaixo um artigo que escrevi no site do projeto SPIDER on Rails:

O termo “mito” é, por vezes, utilizado de forma pejorativa para se referir às crenças comuns.
E existe uma cresca comum que geração de código é algo ruim em projetos.

Encarnando os MythBusters vamos tentar analisar objetivamente se esse mito é válido.

A geração de código é a capacidade de gerar artefatos a partir de diagramas, templates ou até comandos.

Um fato constatável é que alguns desenvolvedores são um pouco resistentes ao termo “Geração de Código”.
As principais reclamações são:

  • O código gerado não respeita nenhuma regra de arquitetura, é simplesmente “um monte de código” de má qualidade;
  • Não é possível manter o código gerado porque ele não segue nenhum padrão e é difícil de entender, sempre é necessário regerar o código em caso de mudanças;
  • Após gerar o código a minha aplicação fica sempre depedente da ferramenta de geração, sem ela o projeto não pode ser alterado;

Dada à diversidade de ferramentas dessa área, estes pontos parecem estar corretos. É fácil encontrar esses tipos de problemas e limitações.
Indo mais além, muitos de nós já se deparou com projetos que prometiam criar um sistema por completo usando geração de código (ferramentas CASE), porém sabemos que isso não é a realidade. Não podemos substituir as pessoas, os programadores, criar regras de negócios automaticamente, prever e implementar soluções para todos os cenários somente gerando código. O computador não possui autonomia para sozinho atender aos nossos clientes exigentes =)… Muito menos foi projetado para tomar todas as decisões no lugar das pessoas.

Então o mito tem fundamento? Geração de código é realmente algo ruim? Vai gerar código que não preciso e atrapalhar o meu projeto?

Essas questões são interessantes, e para buscar uma resposta precisamos isolar os problemas e conceitos, entender o que de fato é geração de código e de onde vem todo o problema.

Ferramentas CASE e similares

Essas ferramentas criadas na década de 90 são responsáveis por boa parte das promessas de “mágica” utilizando geração de código através de modelos. Muitas dessas ferramentas prometiam criar sistema inteiros sem programar nenhuma linha de código. Foi uma estratégia que nunca deu certo e essas falsas promessas surgiram de algumas empresas e das ferramentas e não do conceito de geração de código que é utilizado até hoje (mesmo sem percebermos) em quase todos os softwares que desenvolvemos.

Geração de código

Neste tópico o objetivo é descobrir porque praticamente todo projeto usa geração de código e o que de fato é isso.

Alguns exemplos comuns a todos os projetos:

  • Um wizard da IDE para criar novos projetos é um gerador de código. A partir de dados informados pelo usuário, a ferramenta vai gerar artefatos (arquivos) que inicializem um novo projeto.
  • Por mais estranho que possa parecer, a compilação de código fonte em arquivos binários é geração de código. A partir de comandos de uma linguagem de alto nível são gerados artefatos de outra linguagem de máquina (baixo nível).

Esses exemplos podem parecer polêmicos para alguns pontos de vista, mas a verdade é que não existe uma definição precisa sobre o conceito de geração de código. Existem opiniões e interpretações diferentes que nos levar a ter um certeza – geração de código é algo muito mais amplo do que conhecemos na maioria das ferramentas e é utilizado com muito mais frequencia do que imaginamos.

Vejamos por exemplo o que diz a Wikipedia:
“Gerador de Código é aquela ferramenta que possui a capacidade de gerar código a partir de um determinado modelo de software. Inclusive, de acordo com alguns pontos de vista e a partir das características específicas do tipo de Gerador de Código, ele passa a ser conversor de códigos de linguagens distintas. Isso acontece, por exemplo, com o compilador, que transforma um código escrito através de uma linguagem de programação para código de máquina ou código objeto.”

Já Kathleen Dollard em 2004 no livro Code Generation in Microsoft .NET, foi mais genérica ainda ao definir: “Geração de código é o código que gera código”. Em 2003, Jack Herrington no livro Code Generation in Action preferiu dividir a geração de código entre passiva e ativa. Onde os wizards seriam um exemplo de geração passiva, pois não mantém responsabilidade com o código gerado – qualquer alteração depois da geração é realizada pelo desenvolvedor manualmente, e o tipo ativo que segundo ele mantém a responsabilidade – um código poderia ser gerado em ciclos e quando precisasse de alterações o desenvolvedor recorreria novamente a ferramenta de geração, forneceria novos dados e seria gerado o código de novo.

Aqui não vamos dividir a geração de código em tipos, até porque seguindo ao pé da letra as definições de Herrington, o projeto SPIDER on Rails não faz geração de código 100% ativa nem passiva, ele é orientado as necessidades do desenvolvedor, podendo se comportar das duas formas no mesmo projeto inclusive. O que temos que ter em mente é que se havia alguma dúvida, agora é fato: a Geração de Código faz parte do dia a dia dos desenvolvedores e todos a utilizam, mesmo sem perceber. Ela é extremamente importante para evitar tarefas repetitivas ou trabalhosas, já que muitas podem ser automatizadas de alguma forma para ganhar produtividade. Só devemos lembrar que em nenhum momento a geração de código tem como objetivo fazer tudo sozinha.

Conclusão

Voltando a pergunta: “Geração de código é realmente algo ruim? Vai gerar código que não preciso e atrapalhar o meu projeto?”

A resposta é não! Geração de código não é ruim, não vai atrapalhar o seu projeto e nem tem o objetivo de criar código totalmente pronto.

Existem algumas características que devem que existir para que a geração de código seja algo útil, entre elas:

  • Suporte a templates para alterar o comportamento da ferramenta;
  • Seja fácil de utilizar;
  • O projeto tem que continuar sem depender da ferramenta de geração de código;
  • Ao gerar o código novamente a ferramenta não pode apagar as customizações do desenvolvedor;
  • Não tentar fazer o projeto todo gerando código, as pessoas são importantes e elas devem tomar as maiores decisões. A ferramenta é apenas um suporte para melhorar a produtividades em alguns pontos;

São esses e outros pontos que valorizamos no projeto SPIDER on Rails.

fonte: http://www.spideronrails.org/cnf/pages/viewpage.action?pageId=5111911

Case Study mundial de IBM Rational Team Concert

Bruno Braga on September 8th, 2009

A GlobalValue (GVS), já era referência no Brasil sobre IBM Rational Team Concert (RTC), e a poucos dias atrás concluímos mais um passo desse trabalho. O pessoal da IBM internacional gostou da nossa implementação e agora somos Case Study mundial de RTC.

Eles disponibilizaram várias informações sobre nossa implementação no site www da IBM com acesso livre para todos que tiverem interesse:

http://www-01.ibm.com/software/success/cssdb.nsf/CS/CCLE-7UZUKJ

Há um link para o PDF a direita.

Essa ferramenta tem ajudado a resolver muitos problemas do nosso dia a dia e esse Case Study foi muito bacana porque poucas empresas do Brasil tem referencias publicadas nesta database. Sinal que estamos fazendo coisas boas e no caminho certo :)

Para quem trabalha com desenvolvimento de software e ainda não conhece o RTC, não deixe de espiar o site jazz.net. A ferramenta é 3 em 1 (controle de mudança, controle de versão e integração continua) e possui muitos recursos para desenvolvimento agil (como SCRUM) e também pode ser utilizada em outro cenários mais tradicionais.

Informações sobre este case também foram apresentados nos eventos Rational Comes to You em várias cidades este ano.

IBM Rational Software Conference 2009

Bruno Braga on June 17th, 2009

Dos dias 31 de maio a 04 de junho aconteceu em Orlando, FL o Rational Software Conference 2009.

Estive presente no evento pela primeira vez e vou tentar compartilhar minhas impressões. Alias é muito difícil resumir o que foi um evento desse porte porque existiam muitas trilhas e assuntos paralelos e não é possível acompanhar tudo ao mesmo tempo. No meu caso priorizei a parte de gerenciamento de projetos, gerenciamento de requisitos e gerencia de configuração.

Mas independente das trilhas, como era de ser esperar duas palavras ditaram a maioria dos temas do evento: Agile e Jazz.

Falando em Agile, a vários anos a IBM tem como lider de desenvolvimento Agile um dos mentores do desenvolvimento agil: Scott Ambler mas o termo Agile só começou a ser muito difundido pela IBM em 2008 as vésperas do lançamento do RTC (Rational Team Concert) que foi totalmente desenvolvido com metodologia ágil e destinado a equipes ageis (apesar da ferramenta ser flexível e pode ser utilizada com RUP e outras metodologias).

Neste ano as palestras sobre Agile mostraram como utilizar ferramentas IBM Rational para desenvolver software usando metodologia ágil e também deram uma visão aos usuários RUP (Rational Unified Process) que alguns pontos dos seu processo poderiam ter conceitos ageis, o que de certa forma já era conhecido através do OpenUP. Foi mostrado alguns cases de sucesso dessas abordagens.

Em relação a plataforma Jazz, a IBM fez o anuncio de algumas ferramentas como o Rational Focal Point for Project Management que é uma ferramenta de Portfolio de Projetos e vem com o objetivo de substituir o antigo Rational Portfolio Management e ser 100% compativel e integrado com a plataforma Jazz e o RTC. Foi anunciado também o Rational Insight para relatórios, gráficos e acompanhamento da evolução dos projetos. Ele é um produto baseado no IBM Cognos (ferramenta de BI) e acessará a base de dados de todas as ferramentas Rational com a possibilidade de fazer o cruzamento de dados. Falando em novas ferramentas, aconselho a leitura do meu post anterior: Novo ALM da IBM.

Para empresas que estão preocupadas na evolução continua do desenvolvimento de software e usam ou pretendem usar produtos IBM Rational para aumentar a produtividade, aconselho fortemente a participação no RSC. A possibilidade de conseguir informações diretamente na fonte com desenvolvedores e gerentes dos produtos é sensacional. Além é claro do tamanho do evento e diversidades de assuntos e tendências.

Seguem algumas fotos do evento:

Rational Labs:

Palestra sobre ALM e Jazz:

Scott Ambler e Grady Booch:

Mais fotos:

http://www.flickr.com/groups/rsc2009/pool

Novo ALM da IBM

Bruno Braga on May 10th, 2009

Para quem trabalha com desenvolvimento de software, é importantíssimo ter boas ferramentas para auxiliar e facilitar  o trabalho da equipe.
A integração entre essas ferramentas e conseqüentemente entre o trabalho das pessoas também é desejavel, e é realizada por soluções ALM (Application Lifecycle Management) que cuidam de todo o ciclo de vida da construção do software.

Dois exemplos de empresas que possuem soluções ALM são a Borland e a IBM, e esta última está “repaginando” seus softwares (especificamente da brand Rational) com novos lançamentos desde o ano passado.
Como usuário vejo essa reformulação sendo construída em cima de dois pilares importantes:

  • integração mais transparente entre as ferramentas – todas estão utilizando como base a plataforma Jazz desenvolvida pela IBM;
  • foco em web 2.0 e tecnologias modernas – neste ponto não confunda web 2.0 com ajax, existe muitas outras coisas por tras como usabilidade, experiência do usuário, customização, etc…;

O Rational Team Concert

O primeiro grande lançamento (junho 2008) utilizado plataforma Jazz foi o Rational Team Concert (RTC) que é uma ferramenta excelente de Software Configuration Management e Change Management, e já comentamos sobre ele aqui no blog. Inclusive me arrisco a dizer que o RTC é o melhor sofware IBM Rational atualmente. Ele ainda não é tão difundido no Brasil porque é relativamente novo, mas tem futuro!

Outros lançamentos 2008

O RTC foi o primeiro passo, o caminho a ser seguido por outras ferramentas Rational. E como era de se esperar no final de 2008 foi lançado o Rational Quality Manager (RQM) e Rational Requirement Composer (RRC) que também usam a plataforma Jazz.

Um pequeno inconveniente é que apesar de utilizar a mesma tecnologia, a versão 1.0 do RTC, RRC e RQM trabalham em databases separadas (não podem compartilhar o mesmo banco) e isso dificulta a integração de usuários e dados dos projetos.

Mas todos estes itens estão sendo tratados pela IBM de forma muito transparente no site jazz.net e uma integração maior entre o RTC, RRC e RQM está previsto para a versão 2.0 que será lançada em junho de 2009.

Um bom link para verificar essa integração funcionando é esse post/vídeo no blog dos desenvolvedores:
Surfing the Collaborative ALM web – RTC, RQM, and RRC

Lançamentos 2009

Muitos lançamentos e roadmaps de 2009 serão anunciados no Rational Software Conference 2009 (RSC) que acontece em Orlando a partir do dia 31 de maio.

Vou estar no RSC em Orlando e talvez eu consiga ver de perto algumas novidades.
Mas muitas delas já estão claras a algum tempo e pode ser visto no próprio material de divulgação da plataforma Jazz no jazz.net:

Além dos 3 softwares Jazz (RTC, RQM, RRC) que já foram lançados e estão pertos da versão 2.0, no RSC será divulgado um novo software de “Enterprise Reporting” para extrair dados e relatórios dos projetos e um novo software de “Project Management” já que o Rational Portfolio Management foi descontinuado. Como é possível ver na figura, todos eles utilizarão a plataforma Jazz.

Por questões profissionais já sei o nome dessas novas ferramentas e participo do programa beta delas (restrito), mas por enquanto não posso divulgar muitos detalhes.

Para terem uma idéia do que é esse novo ALM, atualmente os projetos da plataforma Jazz consomem o maior investimento da IBM na área de softwares em comparação entre as brands – Websphere, Lotus, Rational, etc… Além de um investimento pesado, a equipe é formada por profissionais do projeto Eclipse e grandes nomes como Erich Gamma, Grady Booch, Scott Ambler. Com esse foco todo não da para duvidar do sucesso dessa empreitada.

Análise: Compra da SUN pela Oracle

Bruno Braga on April 20th, 2009

Como muitos já sabem, as Oracle anunciou hoje que está comprando a SUN Microsystems.

No GUJ as pessoas estão trocando opiniões com o objetivo de avaliar se isso é ou não uma boa notícia e comparando com a tentativa anterior de compra por parte da IBM.

Como postei no GUJ, sem ver as estrategias de cada empresa a médio / longo prazo não da para dizer que vai ser melhor com a Oracle, IBM ou outra companhia.
Qualquer preferencia seria chute ou opinião pessoal. Existem muitas coisas envolvidas em um negocio deste tipo.

Mas eu espero que o Java tenha uma atenção maior da nova empresa, mais investimento e que isso torne mais rápido nas decisões e implementações do JCP.

O que me preocupa no momento é que a Oracle não tem perfil Open Source como a SUN (java, solaris) / IBM (eclipse, team concert, dojo, geronimo, etc…).

O caminho para o Java crescer na minha opinião não é com a logo da Oracle ou de qualquer outra empresa. O caminho é criando / mantendo uma estrutura separada “Java Foundation” ao estilo “Eclipse Foundation” que seja mantida / gerenciada por uma grande companhia mas que ao mesmo tempo esteja aberta a contribuição de outras empresas / pessoas.
É isso que a Oracle precisa aprender a fazer e espero que comece buscando experiências dentro da SUN.

Se em algum momento da transição começarem a levar a SUN para dentro do site da Oracle como “produto / tecnologia Oracle”, já ferrou com as outras empresas. Na minha opinião, não é disso que Java precisa.

Por questão de ego/concorrência uma empresa que investia em Java pode passar a investir em PHP, outra em Ruby e ai os players podem acabar divididos em relação a linguagem.
Se isso acontecer quem vai rir é a Microsoft que vai ter mais moleza ainda com o .Net e tecnologias para desenvolvimento corporativo.

Portanto a minha “dica” é: o foco em Open Source e em uma estrutura separada é importante.
Espero que a Oracle tenha ainda comprometimento e investimento neste modelo :)

Agora é esperar para ver o que vai acontecer a médio prazo.

Requisitos não funcionais

Bruno Braga on February 12th, 2009

Um colega me perguntou ontem sobre o levantamento de requisitos não funcionais em sistemas, então vou aproveitar que estou devendo posts aqui e falar sobre isso.

Conceito

Requisitos não-funcionais descrevem qualidades do sistema (como o sistema é) ao invés de suas funcionalidades (o que ele faz).

A qualidade afeta diretamente a satisfação do cliente e envolvidos com o sistema. Por isso requisitos não funcionais são importantes. A idéia é explorar essa questão para ter um cliente mais feliz no final do projeto.

A qualidade de um software pode ser avaliada de duas maneiras. A qualidade visível para o usuário final e a qualidade interna visível em tempo de desenvolvimento (mas que permite ou não evoluções do software).

Exemplos

Requisitos de qualidade visíveis ao usuário

  • Usabilidade: resista a solicitações como “O software deve ser amigável para o usuário”. Isso não é suficiente. Explore o assunto e questione: “Como podemos testar e garantir que o software é amigável? O que é esperado?”. Provavelmente o cliente responda: “Eu quero que o usuário não precise dar mais de 3 clicks para acessar as informações e possa acessar a ajuda online de qualquer página do sistema”. Pronto. Conseguimos extrair um requisito não funcional de usabilidade.
  • Performance: “Todo o sistema deve ter a melhor performance possível” também não é um bom requisito de performance. Em um sistema grande nem sempre todas as partes do software tem que ter a mesma performance. Se explorarmos o assunto com o cliente muitas vezes ele pode dizer: “A parte principal do meu software é o cadastro e atendimento de solicitações e várias atendentes cadastram novas solicitações o tempo todo. Para ter produtividade o preenchimento e processamento desse cadastro não pode demorar mais do que 30 segundos. Mas os outros cadastros não são tão críticos”. Isso é um requisito não funcional mais adequado e possível de ser implementado. Os desenvolvedores podem focar no que realmente é importante, fazer politicas de cache para esse caso e outras estrategias sem aumentar o custo do software como um todo.

Geralmente em tempo de levantamento de um software o usuário não se lembra de informar os requisitos não funcionais. Ele está preocupado com as funcionalidades do sistema. Por isso o Analista de Requisitos  deve explorar e questionar esse assunto.
Segue um questionário que pode ser utilizado para iniciar a conversa sobre esse tema:

Questionário

  1. Quantas pessoas vão utilizar o software? Desse número, quantas utilizarão simultaneamente? (não precisa ser um valor fechado… pode ser um range: entre 100 e 200 pessoas utilizarão e é esperado que no máximo 50 utilizem simultaneamente);
  2. Dos relatórios previstos, quais podem ser gerados por processamento batch (de madrugada) e quais devem ser online (com dados do momento)? Qual o tempo aceitável para processar e gerar um relatório online?
  3. Qual o tempo de resposta esperado para as principais funcionalidades do sistema? E para as outras?
  4. Qual tipo de acesso a aplicação vai ter? Somente via intranet? Internet?
  5. Qual o perfil dos usuários que vão acessar a aplicação? Possuem conhecimento de internet? São usuários avançados?
  6. É desejável que a maior parte das funcionalidades da aplicação possam se acessadas via teclado (sem auxilio do mouse)?
  7. A aplicação deve ser compatível com quais versões do browser e/ou sistema operacional?
  8. Quais os padrões de implementação esperados? Os desenvolvedores podem escrever o código em qualquer idioma? Podem utilizar qualquer banco de dados e qualquer tecnologia?
  9. Qual a segurança esperada para o trafego de dados? Toda comunicação entre o servidor e o browser tem que ser criptografada usando SSL? Será adquirido o certificado SSL? Ou a aplicação não tem dados criticos e confidenciais / vai ser executada em uma rede segura?
  10. Qual a disponibilidade a aplicação deve ter? O tempo médio entre falhas, tempo máximo para acertar os problemas? Número máximo de bugs em cada versão? Nesse caso a resposta pode ser que aplicação deve obedecer um acordo de SLA ou que existem regras especificas para esse software de acordo com o negocio.

Muitas outras perguntas podem ser criadas para complementar esse questionário. Mas ele é o básico que precisamos saber para mapear os requisitos não funcionais e criar um software mais alinhado com a espectativa de qualidade esperada pelo cliente.

Acompanhando projetos no Rational Team Concert

Bruno Braga on December 20th, 2008

Meu último post foi sobre a campanha de ajuda ao Sr. Ping. Ele estava perdido no espaço e queria fazer contato com sua equipe / projeto. A solução encontrada foi utilizar o Rational Team Concert (RTC), uma ferramenta colaborativa da IBM para suportar o desenvolvimento de software.

Então vamos aproveitar esse tema e ver tecnicamente como é possível acompanhar um projeto no Rational Team Concert através do Load Bars e Progress Bars. Obs: pesquise também outras maneiras de realizar o acompanhamento, como feeds, notifications, reports, etc…

Antes de mais nada, para quem ainda não conhece o RTC ele é baseado na plataforma Jazz, é desenvolvido com ajuda da comunidade (eclipse way), possui conceitos modernos,  foco em desenvolvimento ágil e entre os vários recursos tem controle de atividades, gestão de código, build, times, interation plans, entre outros…

No RTC muitas pessoas tem curiosidade para saber como é calculado as barras de progresso de cada iteração e plano do projeto. O que são aqueles números? Qual a diferença da barrinha verde clara e escura? O que quer dizer a vermelha? Existem vários links do RTC sobre o tema, mas vou resumir o assunto neste post e colocar algumas considerações.
Primeiro vamos entender quais são os dois tipos de barras de progresso:


Load Bars

É uma barra de progresso individual, ela faz o paralelo entre o trabalho alocado para uma membro do time e o tempo restante da iteração.  Essa estatística é uma resposta rápida para: “Eu tenho tempo para terminar todo o meu trabalho previsto nesta interação?”
Assim os gerentes podem realocar atividades de acordo com a carga de trabalho de cada recurso.
Essa informação está disponível na view “Team Central” na seção “Team Load”.
Ao acessar o “Team Load” será exibido um “Load Bar” para cada recurso do time.
Exemplos:

Indica que 18 das 104 horas de trabalho desta iteração já foram alocadas para este recurso. A barra branca (neste contexto) e o label verde indicam que 86 horas de trabalho desse recurso não estão associadas a nenhuma atividade (você tem tempo sobrando) nesta interação.
Seu trabalho está excedendo o tempo disponível: há 137 horas planejadas para você para 104 possíveis nesta interação. Você está sobrecarregado em 33 horas mostradas pelo label e barra vermelha.


Progress Bars

Mostra uma estatística analisando os workitems fechados e abertos. Elas estão disponíveis nos Iteration Plans e devem ser tratadas como: “Considerando todo o trabalho da interação, como estamos no momento? Qual o status?”

Se existe um target (data fim) para a iteração e algum trabalho já foi realizado, é exibida também uma projeção para o plano. A projeção assume que o trabalho futuro será realizado com a mesma velocidade do trabalho já realizado naquele plano.
Então se passaram 9 horas de trabalho e foi completado um trabalho estimado em 3 horas a projeção assume que é necessário 3 vezes mais tempo do que o estimado para o trabalho restante. Esse calculo é comparado com o tempo disponível na iteração. Se for menor você está adiantado. Se for maior você está atrasado de acordo com a projeção.

Um detalhe importante: Para esses cálculos não é necessário lançar horas (time spent). A projeção é calculada considerando o tempo que já passou e a quantidade de trabalho realizado.
O time spent somente será utilizado SE a previsão para realizar a atividade estava errada e foi preenchido o time spent para corrigi-lá, neste caso o esforço da atividade deixa de ser o estimado e passa a ser esse valor do time spent (realizado).
Exemplos:

A barra de progresso mostra que 48 das 219 horas foram realizadas. Não há projeções (a iteração não tem data para finalizar).
Uma barra de progresso com projeção. Ela mostra que 45 das 80 horas foram realizadas e que você está indo melhor do que o esperado. A parte verde clara mostra o quanto você está adiantado nesta projeção.
Você está atrasado 5 horas. A barra mostra que 4 das 21 horas foram completadas. O esperado era que você tivesse completado 9 horas de trabalho e a barra vermelha ilustra onde você deveria estar.


Então resumindo: essas estatísticas são auto-alimentáveis à medida que as datas do projeto vão sendo previstas (data das iterações) e que o trabalho vai sendo realizado pela equipe. Quanto mais verde estiver a barra de progresso melhor está o andamento do seu projeto. O verde claro pode indicar que você estimou errado (mais tempo do que o necessário) ou que tem uma equipe muito boa.
O vermelho nunca é bom. Mesmo que esteja fazendo as tarefas mais difíceis primeiro e pretenda recuperar no final, o vermelho indicaria que a previsão dessas tarefas foi errada.

Utilizando iterações e planos corretamente você tem um feedback online se as estimativas estão corretas e pode agir rapidamente para evitar atrasos no projeto.

Esses dados são um aliado se forem utilizados corretamente.