Você com mais usabilidade

{ Videocast } Metro . designing great apps

noreply@blogger.com (Apolineo) — Sat, 02 Jun 2012 23:37:00 +0000

Com o lançamento do Windows Phone a Microsoft e seu estilo de design Metro começaram a colocar a experiência do usuário como ponto de partida do projeto de uma app imersiva, elegante e refinada.

Enquanto que os aplicativos tradicionais utilizam diversos tipos de elementos visuais que tiram o foco do usuário no conteúdo, no Metro, são removidos para dar lugar a tipografia e deixar o usuário focado no conteúdo.

Os princípios do design Metro são o guia para a construção de apps modernas e empolgantes.

Quer conhecer mais? Assista o videocast da palestra realizada no MspTechDay e no Hackathon de Windows 8.

{ YouTube } Metro . designing great apps

O que é ergonomia para software?

noreply@blogger.com (Apolineo) — Fri, 15 Jul 2011 22:09:00 +0000

Bom, vamos começar pelas origens, a palavra ERGONOMIA vem de duas palavras Gregas: "ergon" que significa trabalho e "nomos" que significa leis.

Atualmente, é usada para descrever a ciência de "conceber uma tarefa que se adapte ao trabalhador, e não forçar o trabalhador a adaptar-se à tarefa".

A ergonomia tem discutido e comprovado que os aspectos humanos do trabalho devem ser considerados, e a situação de trabalho deve ser modificada em função do homem, o qual, deve ser considerado como um ser que acumulou experiências, desenvolveu crenças, estruturou valores, a partir dos quais define seus padrões de atitude e comportamentos (Medeiros, 1994).

Alguns dos aspectos considerados pela ergonomia são:

Competências: um atributo subjetivo sempre relacionadas as atividades a serem desempenhadas, são conjuntos de conhecimentos, de capacidades de ação e de comportamentos estruturados em função de um objetivo e em uma determinada situação (Gilbert, Parlier,1992 in Boterf, 1995);
Saber-fazer: são os conhecimentos procedurais, tal como eles se manifestam na atividade, dquiridos mais pela prática do que pela formação, raramente são verbalizados e dificilmente transmissíveis (Montmollin, 1995);
Erro Humano: o erro muitas vezes é determinado por características do operador (habilidades conhecimentos, experiência), somadas as características da tarefa (objetivos, sistema técnico, ambiente, regras de execução), portanto, a ergonomia analisa estas condições externas ao trabalho e consideram aspectos internos do trabalhador capazes de gerar erros;
Trabalho Prescrito x Trabalho Real: a ergonomia analisa o conhecimento do trabalho prescrito, das regras fixadas, confrontando com o conhecimento do trabalho realmente desenvolvido de forma a reduzir dificuldades relativas às condições de trabalho ou ao seu melhoramento devido ao fato de considerar apenas o trabalho prescrito e não o trabalho real;

MAS, E NA PRÁTICA?

Alguns exemplos das áreas de atuação da ergonomia no ramo de tecnologia da informação:

Na concepção de sistemas computadorizados, de modo a que sejam mais fáceis de utilizar e que haja menor probabilidade de ocorrência de erros durante a sua operação;
Na arquitetura da informação, de modo a que a interpretação e uso de guias, símbolos e interface seja mais fácil e sem ocorrência de erros;

Nesse momento você provavelmente deve estar esperando ver exemplos práticos de sucesso, porém, que tal conhecer coisas que não deram tão certo?

Suponha que um amigo seu te diz que a empresa XYZ S/A está procurando um profissional que se enquadra com o seu perfil, então, você vai até o site deles. Conforme você procura alguma coisa para clicar, veja como o rótulo escolhido para o botão para a seção de empregos pode fazer diferença:

< ÓBVIO

REQUER RACIOCÍNIO >

Empregos!
Click

Hmm.
[alguns milisegundos pensando]
Empregados.
Click

Humm. Talvez seja a área de empregos, mas parece mais que isso.
Eu clico ou continuo procurando?
Click

Todos os elementos da interface do sistema pode nos obrigar a parar, porém, a falta ou a má condução das atividades de ARQUITETURA DE INFORMAÇÃO pode nos obrigar a pensar demais.

Imagine que você acabou de ser contratado(a) para trabalhar como caixa de um restaurante super movimentado no centro da cidade. Então, no primeiro dia de trabalho você olha aquela fila de pessoas querendo pagar, informa o produto que o cliente está comprando e...

O que está errado? A quantidade. Porque? Como e aonde eu corrijo o problema?

Sem mencionar o tom agressivo da mensagem expresso pelo “!”, a melhor abordagem é identificar onde está errado e fornecer informações da provável forma de resolver o problema.

Uma boa mensagem de erro pode reduzir o impacto do erro humano, facilitar o aprendizado do sistema e garantir a satisfação do usuário em relação ao produto, para isso, basta o ANALISTA DE SISTEMA formar mensagens concisas.

Que tal um outro belo exemplo de um péssimo design?

Mas nem sempre o design está péssimo a ponto de ter que ser totalmente refeito.

Repare que com algumas mudanças na paleta de cor, alinhamento e letra (tipografia) o design pode ganhar vida nova:

Na concepção de um sistema de computador (windows, móvel, web, etc), a ergonomia é o resultado de um trabalho bem estruturado de DESIGN, ARQUITETURA DE INFORMAÇÃO e PROGRAMAÇÃO.

Qual sua opinião sobre o assunto?

Porque Investir em Ergonomia e Usabilidade?

noreply@blogger.com (Apolineo) — Mon, 23 May 2011 13:35:00 +0000

Você já viu um bom produto, totalmente funcional, fracassar porque o usuário acha que ele “mais atrapalha do que ajuda”?

Não, isso não é história de vendedor. Vou dar uma dica. Atualmente, uma franquia de chocolates simplesmente prefere tirar o pedido dos clientes em papel do que usar o sistema do PDV da loja!

Quando apresentamos o trabalho de ergonomia e usabilidade, nossa equipe comercial ouve de alguns clientes “Não acredito nesse tipo de trabalho. Meu sistema está perfeito!”, e de outros, “Quero investir em usabilidade, mas não sei por onde começar...”.

Hoje, vamos compartilhar nossa visão para esse tipo de trabalho.

Usabilidade x Ergonomia

O primeiro passo que damos é deixar claro qual é o campo da ergonomia e qual é o campo da usabilidade.

A usabilidade ocupa-se da interação do usuário com a interface através de apresentações (painés de informações, dados, controles, comandos e mensagens) e estruturas de diálogo (o que interliga as entradas dos usuários com as apresentações de novos painéis).

Ou seja, é o casamento entre a inteface do sistema, o usuário que a opera, a tarefa a ser realizada e o ambiente de operação.

Já a ergonomia trabalha a adaptação de um dispositivo ao seu operador e à tarefa realizada.

Para se construir interfaces ergonômicas e que proporcionem usabilidade, os profissionais envolvidos utilizam técnicas e conceitos para organizar os diferentes elementos gráficos de forma a facilitar a percepção, o racioncínio, a memorização e a tomada de decisão.

O que é problema de Ergonomia?

O problema de ergonomia é identificado quando um aspecto da interface está em desacordo com as características dos usuários, por exemplo:

Aspecto inadequado na interface;
Recomendação ou critério ergonômico sendo desrespeitado;

Faça um teste você mesmo, olhe para uma interface do seu sistema e pergunte:

Os rótulos dos campos contêm um elemento específico, por exemplo ":", como convite às entradas de dados?
Nos agrupamentos de dados , os itens estão organizados espacialmente segundo um critério lógico?
Os títulos das páginas de menu são explicativos, refletindo a natureza da escolha a ser feita?

O que é problema de Usabilidade?

Já o problema de usabilidade é observado em determinadas circuntâncias, quando uma característica do sistema interativo (problema de ergonomia) compromete a produtividade, a qualidade da tarefa ou (no pior caso) inviabiliza sua realização e é descrito a partir:

Do contexto de operação onde o problema pode ser observado;
Algum aspecto inadequado na interface (problema de usabilidade);
Frequência com que o problema/contexto se manifesta;

O que faço? Inspeção de ergonomia ou teste de usabilidade?

O teste de usabilidade é um trabalho balisado por um estudo e avaliação que requer um tempo hábil para planejamento, execução e análise (de 2 a 3 semanas, dependendo da quantidade de tarefas a serem avaliadas) e fornece compensadores.

Para produtos com aspectos ou conceitos inovadores o mais indicado é o teste de usabilidade.

A inspeção ergonômica fornece uma resposta rápida e precisa (em média 2 semana, dependendo da quantidade de telas), que dependendo da natureza e dos conceitos do produto, pode até suprir testes de usabilidades.

Mas lembre-se, só é possível realizar inspeções ergonômicas ou testes de usabilidade se o seu sistema está pronto ou se você tem um protótipo funcional do sistema, caso contrário, o designer de interfaces é o investimento mais indicado.

Quero melhorar a qualidade do meu sistema, por onde começo?

Investir em inspeções de ergonomia é o melhor passo, porque, fornece uma resposta rápida da percepção que os usuários podem ter e permite que você conheça melhor os benefícios desse tipo de trabalho e como explorar o diferencial que trará ao seu produto.

A Apolineo realiza esse tipo de trabalho.

Baseado na norma ISO 9241:10, são avaliados 197 itens dispostos em 18 categorias e com pesos de acordo com sua criticidade, onde ao final, é gerado um score da qualidade ergonômica:

BAIXA: a interface precisa ser totalmente reformulada;
REGULAR: a interface possui muitos problemas críticos, corrija-os;
BOA: faça uma revisão dos itens mais críticos;
ÓTIMA: corrigir pontualmente os itens mais críticos (se houver);

Conheça nosso portfólio em http://www.apolineo.com.br/portfolio/.

Até a próxima!

Como vai a ergonomia do seu código?

noreply@blogger.com (Apolineo) — Tue, 03 May 2011 03:26:00 +0000

No mundo RAD (Rapid Application Development) de hoje pouco se discuti sobre a qualidade do código fonte dos nossos softwares.

E se você fizer uma pesquisa no Google encontrará um conteúdo abordando aspectos da ergonomia do código de forma isolada. Nosso intuito com esse artigo é iniciar uma discussão no intuito de identificar e organizar as qualidades qualidades desejadas e como chegar lá...

Após algumas reflexões e analogias com a ergonomia de interfaces chegamos em 6 qualidades que devemos trabalhar:

Acoplamento: diz respeito a qualidade de baixa dependência;
Coesão: diz respeito a qualidade de responsabilidade única;
Flexibilidade: diz respeito a qualidade de extensão e personalização;
Legibilidade: diz respeito ao esforço necessário para compreensão do código;
Mensagens de Erros: diz respeito a qualidade das mensagens de erro;
Presteza: diz respeito a qualidade das informações disponiveis sobre o código para informar e conduzir a utilização do código;

Acoplamento

O acoplamento entre classes ou subsistemas é uma medida da interconexão entre as classes ou subsistemas.

Exemplo de recomendações:

Evitar duplicação de código;
Evitar classes muito grandes;
Evitar métodos muito longos;
Evitar lista de parâmetro muito longas;

O exemplo abaixo ilustra um módulo de processamento de negócios com acoplamento forte. O primeiro problema é que não podemos reaproveitar a regra de negócio independentemente da estrutura do banco de dados, e segundo, que qualquer alteração na estratégia de acesso a dados , na estrutura de dados ou configuração afetará a lógica de negócio.

public class BusinessLogicClass
{
  public void DoSomething()
  {
    int threshold = int.Parse(ConfigurationManager.AppSettings["threshold"]);
    string connectionString = ConfigurationManager.AppSettings["connectionString"];

    string sql = @"select * from things size > " + threshold;

    using (SqlConnection connection = new SqlConnection(connectionString))
    {
      connection.Open();

      SqlCommand command = new SqlCommand(sql, connection);
      using (SqlDataReader reader = command.ExecuteReader())
      {
        while (reader.Read())
        {
          string name = reader["Name"].ToString();
          string destination = reader["destination"].ToString();

          // do some business logic in here
          doSomeBusinessLogic(name, destination, connection);
        }
      }
    }
  }
}

Coesão

A coesão é a medida que indica se uma classe tem uma função bem definida no sistema.

Um sistema composto por classes e subsistemas coesos é semelhante a um grupo de discussão online bem projetado. Cada área do grupo online é estritamente concentrada em um tópico específico, para que seja fácil acompanhar a discussão e, se você estiver procurando um diálogo sobre determinado assunto, precise visitar apenas uma sala.

Exemplos de recomendações:

Utilize o principio de separação de conceitos dividindo as funcionalidades da aplicação e minimizando pontos de interação;
Utilize o principio Least Knowledge (LoD) para evitar que um objeto não conheça os detalhes internos de implementação de outro;
Utilize o principio Tell, Don’t Ask e evite que seus objetos façam perguntas a um objeto sobre seu estado interno, tome algumas decisões sobre esse estado, e então, diga ao objeto o que fazer;
Pratique a Lei de Deméter e faça com que a classe fale somente com seus “amigos” mais próximos;

public class Purchase
{
  private readonly double _subTotal;

  public Purchase(double subTotal)
  {
    _subTotal = subTotal;
  }

  public double Total
  {
    get
    {
      double discount = _subTotal > 10000 ? .10 : 0;
      return _subTotal * (1 - discount);
    }
  }
}

public class Account
{
  private double _balance;

  public void Deduct(Purchase purchase, PurchaseMessenger messenger)
  {
    if (purchase.Total < _balance)
    {
      _balance -= purchase.Total;
    }
    else
    {
      messenger.RejectPurchase(purchase, this);
    }
  }
}

public class ClassThatObeysTellDontAsk
{
  public void MakePurchase(Purchase purchase, Account account)
  {
    PurchaseMessenger messenger = new PurchaseMessenger();
    account.Deduct(purchase, messenger);
  }
}

Saiba mais através do artigo Padrões na prática: coesão e acomplamento

Flexibilidade

A flexibilidade do código é a qualidade que promove a reusabilidade e a facilidade de manutenção (reparo de erro e evolução) para responder de forma rápida e confiável as mudanças exigidas pelo dinâmismo do business das empresas.

Exemplos de Recomendações:

Padronizar a criação de objetos;
Isolar a complexidade de criação de objetos compostos;
Fornecer meios de extender o comportamento das classes;
Fornecer meios de mudar o comportamento das classes;

No exemplo abaixo, temos uma API para importação de dados externos ao sistema através de um conector. Nela isolamos e padronizamos a criação de conectores e fornecemos um meio de extendê-los e ou mudar sua estratégia de leitura das informações externas sem impacto no código.

Você pode fazer o download do projeto clicando aqui.

Legibilidade

A performance e a qualidade na evolução do código leva em conta as características cognitivas e perceptivas dos usuários.

Uma boa legibilidade facilita a leitura do código, a identificação de defeitos, reduz a curva de aprendizado da equipe, promove o reuso e reduz o gap de idioma com a área de negócio.

Exemplos de recomendações:

Usar nomes claros e explicativos para funções (verbos) e variáveis (substantivos);
Fazer com que o código reflita suas intenções e decisões;
Trabalhar a lêxia do código de forma a refletir uma frase natural;
Utilizar o padrão Pascal Case para nomes de namespaces, classes, métodos, propriedades, eventos e delegates;
Utilizar o padrão Camel Case para nomes de variáveis;

Um recurso muito útil introduzido na versão 3.0 do Microsoft .Net Framework é o Extension Method, o qual, podemos adicionar comportamento (método) a um determinado tipo sem a necessidade de alterar o código original ou criar tipos derivados.

Vejamos um exemplo:

if (sale.IsValid() && sale.SaleDetailsList.HasAllItemsValid())
{
  if(Stock.EvaluateProductsAvailability(sale))
  {
    using (var trans = new DataTransaction())
    {
      sale.Insert();
      Stock.UpdateStock(sale.GetProductsSold());
      sale.SaleDetailsList.Insert();
      Invoice.Generate(sale);
      Carrier.PlanDeliver(sale);

      trans.Complete();
    }
  }
}

Mensagens de Erros

A qualidade das mensagens favorece o aprendizado do sistema, indicando ao usuário a razão ou a natureza do erro cometido, o que ele fez de errado, o que ele deveria ter feito e o que ele deve fazer.

Exemplos de recomendações:

Construir mensagem no idioma do usuário;
Utilizar mensagens de erro tão breves quanto possível;
Fornecer mensagens de erro orientadas a tarefas;
Utilizar termos tão específicos quanto possível para as mensagens de erros;
Adotar um vocabulário neutro, não personalizado, não repreensivo nas mensagens de erro;
Evitar o humor;

Vamos avaliar isso em um exemplo.

Ao invés de frases com estrutura negativo-negativo, como “A idade mínima não pode ser menor que 18 anos”, procure utilizar linguagem positiva e indicar os valores esperados, “A idade deve ser maior ou igual a 18 anos”.

Forneça na mensagem de erro todas as informações necessárias à compreensão e solução do problema.

Ao invés de “Desconto superior ao máximo permitido (G527)”, procure alternativas como “O valor de desconto (R$50,00) é superior ao máximo permitido para essa transação (R$7,50). Por favor, tente novamente com valor adequado ou solicite aprovação da supervisão”.

Curiosidade: 10 principais, diferentes e engreçadas mensagens de erro da computação

Presteza

Uma boa presteza facilita o aprendizado do usuário em como usar uma classe/método/serviço e diminui a ocorrência de erros.

Exemplos de Recomendações:

Documentar a responsabilidade da classe;
Documentar o que seus métodos fazem;
Documentar para que serve o parâmetro de um método/serviço, o valor padrão e os valores esperados;
Fornecer um cenário de uso da classe/método/serviço;

Vamos avaliar isso em um exemplo.

Você já usou uma classe de alguém que não se preocupou em escrever aquele cabeçalho do método, ou pior, que escreveu coisas que não ajudam em nada?

Vendo o exemplo acima você deve estar se perguntando: O que a classe XnMSteadyDetector faz? O que o parâmetro “CooldownFrames” controla e qual o range valores válidos? E o parametro “DetectionDuration”? Controla o tempo em segundos, millisegundos, ou outro? Qual é o valor padrão? E o “MaximumAllowedVelocity”?

Alguém pode argumentar “Isso está na documentação”. Perfeito! É o mínimo que tem que ser feito, senão, seria quase impossível usar a classe.

Mas no mundo .Net, onde há o Microsoft Visual Studio, você deveria ir além!

Deveria fornecer informações de forma integrada com o ambiente de desenvolvimento de forma a facilitar a vida da pessoa que está utilizando sua classe/método/serviço.

E isso é simples. Basta:

Para produzir esse resultado:

Fique a vontade para compartilhar suas experiências, visões, sugestões e críticas.

Até a próxima!

Artigos Recomendados:

>>   Event-based Asynchronous Pattern (EAP). O futuro padrão para as interfaces das aplicações?
>>   Software para Pessoas do Séc XXI
>>   Prepare-se para o C# 5 – Parte 2
>>   Prepare-se para o C# 5 – Parte 1
>>   Reflection de Alta de Performance
>>   Extension Methods = Manutenibilidade

Event-based Asynchronous Pattern (EAP). O futuro padrão para as interfaces das aplicações?

noreply@blogger.com (Apolineo) — Wed, 20 Apr 2011 20:43:00 +0000

Sabe quando seu aplicativo vai realizar uma tarefa demorada e ele “para de responder” enquanto não termina de processar? Esse é o cenário de grande parte dos aplicativos atualmente.

Com a versão 2.0 do Microsoft .Net Framework foi introduzido um pattern endereçado a esse tipo de cenário chamado Event-based Asynchronous Pattern (EAP), oferecendo as vantagens de uma aplicação multithreaded e "escondendo" a complexidade inerente a esse tipo de design.

Com ele, você pode:

Executar tarefas demoradas, como downloads e operações de banco de dados, em "background", sem congelar sua aplicação;
Executar operações simultaneamente e receber notificações quando cada uma for concluída;
Aguardar que recursos fiquem disponíveis sem congelar sua aplicação;
Comunicar-se com as operações assíncronas pendentes usando o modelo de eventos;

A efeito de exemplo e aprendizado, o cenário que vamos trabalhar é a leitura de arquivos texto para importação de dados no sistema.

Começamos a implementação do pattern criando as classes de argumento dos eventos que criaremos para nos comunicarmos com o chamador. Essas classes devem herdar do AsyncCompletedEventArgs ou ProgressChangedEventArgs (no caso de informação referente ao progresso da execução).

No nosso caso, a classe padrão (ProgressChangedEventArgs) é suficiente para notificarmos o progresso da leitura e mapeamento dos dados do arquivo. Então, o argumento para a notificação da finalização do processamento ficará:

public class MapCompletedEventArgs : AsyncCompletedEventArgs
{
  public IEnumerable<Customer> CustomersList { get; private set; }
  public MapCompletedEventArgs(IEnumerable<Customer> customersList,
  Exception error, bool isCancelled, object userState)
    : base(error, isCancelled, userState)
  {
    this.CustomersList = customersList;
  }
}

O próximo passo é criar os handles (delegates) para as operações de avisar o progresso e quando o processamento estiver terminado:

public delegate void MapProgressChangedEventHandler(ProgressChangedEventArgs e);
public delegate void MapCompletedEventHandler(MapCompletedEventArgs e);

Agora, criaremos os respectivos eventos para informar o progresso e quando a execução estiver concluída:

public event MapProgressChangedEventHandler MapProgressChanged;
public event MapCompletedEventHandler MapCompleted;

Para garantir o uso da thread correta na execução dos eventos precisamos criar callbacks para serem executados via AsyncOperation:

private SendOrPostCallback onProgressReportDelegate;
private SendOrPostCallback onCompletedDelegate;

A última variável que precisamos é um dicionário para controlar as múltiplas requisições:

private HybridDictionary userStateToLifetime = new HybridDictionary();

No construtor da classe inicializamos os callbacks:

public CustomerMapper()
{
  onProgressReportDelegate = new SendOrPostCallback(ReportMapProgress);
  onCompletedDelegate = new SendOrPostCallback(ContentFileMappingCompleted);
}

private void ContentFileMappingCompleted(object operationState)
{
  OnMapCompleted(operationState as MapCompletedEventArgs);
}

private void OnMapCompleted(MapCompletedEventArgs e)
{
  if (MapCompleted != null)
  {
    MapCompleted(e);
  }
}

private void ReportMapProgress(object state)
{
  OnMapProgressChanged(state as ProgressChangedEventArgs);
}

private void OnMapProgressChanged(ProgressChangedEventArgs e)
{
  if (MapProgressChanged != null)
  {
    MapProgressChanged(e);
  }
}

E finalmente chegamos aos métodos de mapeamento assíncrono do arquivo, o qual, criamos uma operação assíncrona através da classe AsyncOperationManager:

public IAsyncResult MapAsync(string filePath)
{
  var asyncOp = AsyncOperationManager.CreateOperation(filePath);

  lock (userStateToLifetime.SyncRoot)
  {
    if (!userStateToLifetime.Contains(filePath))
    {
      userStateToLifetime[filePath] = asyncOp;
    }
  }

  var action = new Action<string, AsyncOperation>(MapFileWorker);
  return action.BeginInvoke(filePath, asyncOp, null, null);
}

Disponiblizaremos um método para ser utilizado caso o usuário queira cancelar a operação a qualquer momento:

public void CancelReadAsync(string filePath)
{
  var asyncOp = userStateToLifetime[filePath] as AsyncOperation;
  if (asyncOp != null)
  {
    lock (userStateToLifetime.SyncRoot)
    {
      userStateToLifetime.Remove(filePath);
    }
  }
}

No método que realiza o processamento da requisição precisamos garantir que o evento referente a finalização do processamento seja executado em caso de sucesso, cancelamento ou falha. E para executarmos o evento utilizamos o método PostOperationComplete da operação assíncrona que criamos:

private void MapFileWorker(string filePath, AsyncOperation asyncOp)
{
  Exception error = null;
  IEnumerable<Customer>customersList = null;
  if (!TaskCanceled(asyncOp.UserSuppliedState))
  {
    try
    {
      customersList = MapFileLogic(filePath, asyncOp);
    }
    catch (Exception ex)
    {
      error = ex;
    }
  }

  if (!TaskCanceled(asyncOp.UserSuppliedState))
  {
    lock (userStateToLifetime.SyncRoot)
    {
      userStateToLifetime.Remove(asyncOp.UserSuppliedState);
    }
  }

  var arg = new MapCompletedEventArgs(customersList, error,
    TaskCanceled(asyncOp.UserSuppliedState), asyncOp.UserSuppliedState);

  asyncOp.PostOperationCompleted(onCompletedDelegate, arg);
}

Para o evento de acompanhamento do progresso usamos o método Post da operação assíncrona:

var arg = new ProgressChangedEventArgs(progressPercentage, asyncOp.UserSuppliedState);
asyncOp.Post(this.onProgressReportDelegate, arg);

Ao final, a classe que utilizará o método assíncrono ficará assim:

var mapper = new CustomerMapper();
mapper.MapCompleted += new CustomerMapper.MapCompletedEventHandler(mapper_MapCompleted);
mapper.MapProgressChanged += new CustomerMapper.MapProgressChangedEventHandler(mapper_MapProgressChanged);
mapper.MapAsync(Environment.CurrentDirectory + @"\CustomerTextFile1.txt");

E talvez você esteja se pergutando “Legal, e por que eu deveria me importar com isso?”.

Essa é uma tendência de programação que ganhou força com o Silverlight e parece ser o padrão para se programar no Windows Phone 7.

Será que esse pattern se tornará padrão para programação de aplicações no futuro?

Você já usou esse padrão?

Até a próxima!

DOWNLOAD EXEMPLO:
EAP.TEXTFILEMAPPER.RAR

Artigos Recomendados:

>>   Software para Pessoas do Séc XXI
>>   Prepare-se para o C# 5 – Parte 2
>>   Prepare-se para o C# 5 – Parte 1
>>   Reflection de Alta de Performance
>>   Extension Methods = Manutenibilidade

Software para Pessoas do Séc XXI

noreply@blogger.com (Apolineo) — Wed, 13 Apr 2011 01:49:00 +0000

Antigamente quando você dizia “Chefe, chefe, estou com uma grande idéia”, ele te dizia, “Calma. Respira fundo que passa.”

Hoje, as necessidades mudaram. As pessoas estão se despedindo dos seus chefes e apenas em 2011 foram 163.679 formalizações de empreendedores individuais segundo o Sebrae.

Antes, ao comprar uma televisão você virava um consumidor, agora, ao comprar qualquer eletrônico você se torna um produtor. Já percebeu quanto material é produzido por pessoas como você em eventos, festas, desastres, etc? Somos mais rápido que a imprensa!

O tempo virou o bem social coletivo. Relevância, a palavra chave nesse mar de informação. E co-criação a saída de uma vida moderna sem significado. Você conhece o Camiseteria? Ou o Electrolux Design Lab? Talvez o Fiat Mio? Provavelmente o Nespresso? Mas com certeza o Wikipedia!

As pessoas mudaram. Você mudou! Só que as empresas ainda criam software como na época do “Departamento de Processamento de Dados”? rs

"Empresas que compreendem a importância de aproveitar o poder dos comportamentos colectivos para impulsionar mudanças positivas nos negócios serão bem-sucedidas." – Gartner

Em projetos de softwares modernos além da arquitetura do software, da estrutura de dados, da distribuição e da sergurança precisamos considerar as capacidades e limitações dos usuários, de forma a tornar o trabalho deles mais eficaz, eficiente e agradável.

Para isso, primeiramente sua metologia deve promover o envolvimento do usuário no projeto.

Como o usuário é a pessoa que mais conhece sobre o contexto do seu trabalho, sem desconsiderar o risco de perda de tempo e recursos em função da variabilidade e subjetividade que caracterizam as atividades com usuários, devemos desenvolver técnicas para planejar, organizar e executar o envolvimento adequado, que pode ser:

Informativo: o usuário é visto como fonte de informação que são extraídas através de técnicas de entrevistas, questionários ou observação;
Consultivo: o projetista, valendo-se ou não das informações coletadas, elabora soluções de projeto e pede que o usuário as verifique e emita uma opinião;
Participativo: quando a corporação transfere ao usuário o poder sobre as decisões de projeto e requer alto engajamento (que deve vir desde a alta gerência);

Durante a especificação do sistema e o desenvolvimento do protótipo você deve trabalhar os 5 fatores da experiência do usuário:

Utilidade: percepção do usuário quanto a funcionalidade lhe agregar algum valor dentro do seu contexto;
Usabilidade: diz respeito à eficácia, eficiência e satisfação do usuário na realização de seus objetivos com o sistema;
Disponibilidade: refere-se aos elementos da interface que fornecem feedback sobre o estado do sistema, mecanismos que evitem perda de informação, etc;
Estética: refere-se ao apelo visual da aplicação, à sua atratividade para o usuário;
Processo off-line: complementa a experiência do usuário, como a confiança no nome da empresa, a segurança dos dados, suporte, treinamento, campanha de marketing, entre outros;

O IPhone é um exemplo de produto criado com esse tipo de abordagem.

O que achou? Deixe seus comentários.

Até o próximo!

Redes Sociais no Ambiente Corporativo

noreply@blogger.com (Apolineo) — Wed, 30 Mar 2011 15:04:00 +0000

Quando você leu o título o que lhe veio a cabeça? Twitter? Facebook?

Hum, se sua resposta for sim, sinto em lhe dizer, mas você está confundindo MÍDIA SOCIAL com REDE SOCIAL.

“Qualquer pessoa ficaria chateado, qualquer um de nós ficaria abatido, desmotivado, mas não Joseph Klimber” e você também não precisa.

Então, o que é uma rede social?

Rede social é uma estrutura composta por pessoas conectadas que compartilham valores e objetivos comuns. Isso quer dizer que o grupo que se reúne todos os domingos para jogar bola, as pessoas que participam do Campus Party ou o grupo de voluntários da GRAAC são todos redes sociais (só que em diferentes níveis).

Com a aparição de novas tecnologias como a internet a interação entre as pessoas cresce com rapidamente. Então, com a criação de mídias sociais como o Youtube, o Twitter ou Facebook essa velocidade aumentou ainda mais. São milhões de pessoas colaborando, compartilhando, co-criando, presentes em todos os lugares e em busca de um mundo melhor.

“Empresas que compreendem a importância de aproveitar o poder dos comportamentos colectivos para impulsionar mudanças positivas nos negócios serão bem-sucedidas.” – Gartner

E porque na minha empresa não é assim?

Quando dentro de uma empresa buscamos conhecimento para atingirmos uma meta, realizar um trabalho, só que a máquina da empresa, a obrigação, a rotina, seus processos não permitem troca de conhecimento, e esse ambiente inadequado, inibe a interação das pessoas.

Ninguém interage se não vê essa troca.

Para estabelecer relações precisam ser criadas conexões, as quais podem gerar ou não relações de confiança, onde geralmente, a troca de conhecimento pessoal começa a acontecer.

Talvez você já tenha experimentado isso de alguma forma. Você já conversou sua vida pessoal com algum colega do trabalho que você não confia? Mas já deve ter considerado o comentário de um desconhecido sobre um produto que você queria comprar.

Uma vez que as pessoas começam a trocar informações pessoais elas se viciam nisso e esse caminho evolui para o ambiente profissional.

Nessas conexões haverá pessoas com diversos perfis e nosso trabalho será identificar o perfil de cada um e incentivá-las. Os principais perfis são os CRIADORES (aquelas que geram conteúdo para outras pessoas), CRÍTICOS (aquelas que opinião sobre os conteúdos gerados), PARTICIPANTES (aquelas que participam comentando ou interagindo com o conteúdo gerado) e os ESPECTADORES (aquelas que apenas acompanham esses conteúdos).

Você deve estar se indagando, isso é bonito, mas sem controle vai virar uma bagunça!

O “controle” muda para moderação, bom senso, política de boa conduta. E isso a própria rede é capaz de “controlar” se as pessoas críticas entenderem a política da rede. Alias, VOCÊ DEVERIA SER UMA DESSAS PESSOAS COM PERFIL CRÍTICO!

Estamos na era da Economia da Colaboração. As pessoas agora interagem para a CO-CRIAÇÃO do conhecimento em busca de um mundo melhor. Então, permita de alguma forma que seu cliente ou colaborador faça parte do processo criativo e produtivo do projeto.

E porque as pessoas dedicam seu precioso tempo na co-criação de um produto?

1. Fazer parte de algo maior
2. Mostrar que fazem parte daquilo
3. Pura diversão
4. Oportunidade de colaborar
5. Recompesa financeira

Já está acontecendo. É real! Não conhece a CAMISETERIA, o NESPRESSO, o FIAT MIO, o DESIGN LAB ELECTROLUX ou ainda o WIKIPEDIA.

Contudo, nada disso faz sentido se não aprendermos, não compartilharmos, não inovarmos, não criticarmos, não participarmos. E para isso, são necessárias estratégias, capacitação, metodologias específicas e projetos.

Como é o ambiente na sua empresa? É colaborativo? Participativo? As pessoas se sentem confortáveis em expressarem suas opiniões? Torcem o nariz quando houvem falar de rede social? E qual sua opinião sobre o assunto?

PARTICIPE DA DISCUSSÃO NO FACEBOOK!

Artigos Recomendados:

>> Pensando em ERGONOMIA e USABILIDADE
>> Design centrado no usuário

Prepare-se para o C# 5 – Parte 2

noreply@blogger.com (Apolineo) — Tue, 29 Mar 2011 21:31:00 +0000

Demorou mais chegou... rs

No último artigo mostramos que a expressão document = await Fetchasync(urls [i]) do C# 5.0 era realizada assim:

state = State.AfterFetch;
fetchThingy = FetchAsync(urls[i]);
if (fetchThingy.SetContinuation(archiveDocuments))
return;
AfterFetch: ;
document = fetchThingy.GetValue();

Nesse modelo, um método assíncrono retorna um Task<T>, e por hora, vamos assumir que o FetchAsync também retorne um Task<Document>. Então, o código atual será realizado assim:

fetchAwaiter = FetchAsync(urls[i]).GetAwaiter();
state = State.AfterFetch;
if (fetchAwaiter.BeginAwait(archiveDocuments))
return;
AfterFetch: ;
document = fetchAwaiter.EndAwait();

A chamada a FetchAsync cria e retorna um Task<Document>. Ao chamar este método ele imediatamente retorna um Task<Document> que de alguma forma busca o documento desejado de forma assíncrona. Para fazer alguma coisa quando ele estiver completo buscamos na tarefa por um Awaiter, e ele fornece 2 métodos: BeginAwait, assina a continuação para a tarefa (executado após a finalizada a tarefa) e o EndAwait, que extrai o resultado da tarefa finalizada.

Como esses métodos são implementados na Task (para métodos void) ou Task<T> (para métodos que retornem valor) como fica os métodos que não retornam Task ou Task<T>?

Nesse caso é utilizado a mesma estratégia do LINQ, ou seja, se tivermos:

From c in customers where c.City == "London"

Isso é traduzido para:

Customers.Where(c => c.City == "London")

E uma resolução de overload tenta encontrar o melhor método "Where" checando se a implementação de "Customers" implementa tal método, caso contrário, busca por métodos de extensão.

Com o padrão GetAwaiter/BeginAwait/EndAwait é a mesma coisa, é feita a resolução de overload na transformação da expressão, verificado o método ou a extensão adequeada.

O insight é que assincronia não requer paralelismo, mas o paralelismo exige assincronia, e muitas das ferramentas úteis para o paralelismo podem ser usadas para assincronia sem paralelismo.

Por isso o uso do Task, ele não possui paralelismo inerente e podemos representar unidades de trabalho pendentes que pode ser paralelizada e não requer multithreading, além de, já possui mecanismos de cancelamento entre outras características úteis da TPL (Task Parallel Library).

Voltando ao exemplo da busca de documentos, ele foi deliberadamente planejado para demostrar o pulo do gato, o CPS (Continuation Passing Style), para controlar até mesmo orquestrações simples de 2 tarefas assíncronas de métodos void.

Então, vamos falar um pouco sobre composição de métodos assíncronos.

Suponha que o método ArchiveDocuments retornasse o número total de bytes arquivados:

long ArchiveDocuments(List<Url> urls)
{
  long count = 0;
  for(int i = 0; i < urls.Count; ++i)
  {
    var document = Fetch(urls[i]);
    count += document.Length;
    Archive(document);
  }
  return count;
}

Agora, vamos reescrevê-lo de forma assíncrona usando um CPS:

void ArchiveDocumentsAsync(List<Url> urls, Action<long> continuation)
{
// de alguma forma executa a busca de forma assíncrona,
// depois invoca sua continuação
}

Dessa forma, o chamador do ArchiveDocumentsAsync precisaria ser escrito em um CPS de modo que a continuidade possa ser passada. E se o retorno fosse um resultado? Então, seria uma confusão.

No modelo TAP (Task Asynchrony Pattern, nome provisório para essa feature de composição de métodos assíncronos), ao invés disso, diriamos que o tipo que representa o trabalho assíncrono e retorna um valor é um Task<T>. Em C# 5, você poderia simplesmente escrever:

async Task<long> ArchiveDocumentsAsync(List<Url> urls)
{
  long count = 0;
  Task archive = null;
  for(int i = 0; i < urls.Count; ++i)
  {
    var document = await FetchAsync(urls[i]);
    count += document.Length;
    if (archive != null)
      await archive;
    archive = ArchiveAsync(document);
  }
  return count;
}

E o compilador se encarregará de reescrever e gerar algo como:

Task<long> ArchiveDocuments(List<Url> urls)
{
  var taskBuilder = AsyncMethodBuilder<long>.Create();
  State state = State.Start;
  TaskAwaiter<Document> fetchAwaiter = null;
  TaskAwaiter archiveAwaiter = null;
  int i;
  long count = 0;
  Task archive = null;
  Document document;
  Action archiveDocuments = () =>
  {
    switch(state)
    {
      case State.Start: goto Start;
      case State.AfterFetch: goto AfterFetch;
      case State.AfterArchive: goto AfterArchive;
    }
    Start:
    for(i = 0; i < urls.Count; ++i)
    {
      fetchAwaiter = FetchAsync(urls[i]).GetAwaiter();
      state = State.AfterFetch;
      if (fetchAwaiter.BeginAwait(archiveDocuments))
        return;
      AfterFetch:
      document = fetchAwaiter.EndAwait();
      count += document.Length;
      if (archive != null)
      {
        archiveAwaiter = archive.GetAwaiter();
        state = State.AfterArchive;
        if (archiveAwaiter.BeginAwait(archiveDocuments))
          return;
        AfterArchive:
        archiveAwaiter.EndAwait();
      }
      archive = ArchiveAsync(document);
    }
    taskBuilder.SetResult(count);
    return;
  };
  archiveDocuments();
  return taskBuilder.Task;
}

Vamos fazer um teste de mesa aqui para clarear as coisas.

O que acontece quando a lista está vazia? Nós criamos um contrutor de tarefas, um delegate que retorna void e invocamos ele de forma assíncrona. Ele inicializa a variável ”count” com 0, executa a label start, pula o loop, diz para o helper “você tem um resultado” e retorna. Finaliza o delegate. O taskbuilder é solicitado para uma tarefa, e uma vez que ele sabe que a tarefa foi concluida, retorna a tarefa concluida que simplesmente representa o número 0.

E caso existam vários documentos de arquivos? Novamente criamos um taskbuilder e um delegate que serão invocados assíncronamente. No primeiro loop começamos uma busca assíncrona, assinamos o delegate como sua continuação e retornamos do delegate. O taskbuilder contrói uma tarefa que representa “estou trabalhando de forma assíncrona no corpo do ArchiveDocumentsAsync” e retorna essa tarefa. Ao ser concluída, invoca sua continuação e o delegate inicia de novo “do ponto onde ele parou” graças a máquina de estado. Tudo continua exatamente como antes, porém, direferente da versão void, o Task<long> retornado para o ArchiveDocumentsAsync sinaliza que finalizou (invocando sua continuação) e o delegate diz ao task builder para definir o resultado.

NOTA:Tal qual o LINQ, o TAP pode ser extensível por qualquer tipo que tenha um GetAwaiter, que retorne um tipo que tenha BeginAwait, EndAwait e assim por diante, para que possa ser usado nas expressões “await”. Contudo, métodos marcados para serem assíncronos devem retornar void, Task ou Task<T>.

Existem situações onde sintaxe com tokens como “where” do LINQ são mais naturais e outras onde são a sintaxe “fluent” .Where(c => ...), no TAP haverá métodos com nomes como WhenAll ou WhenAny para compor e orquestrar tarefas assíncronas:

List<List<Url>> groupsOfUrls = whatever;
Task<long[]> allResults = Task.WhenAll(
from urls in groupsOfUrls
select ArchiveDocumentsAsync(urls));
long[] results = await allResults;

O que isto faz? Bem, o ArchiveDocumentsAsync retorna um Task<long>, então a query retorna um IEnumerable<Task<long>>. WhenAll pega a sequência de tarefas e produz uma nova tarefa, que de forma assíncrona aguarda cada um deles, preenche um array com o resultado e invoca sua continuação com o resultado quanto ele estiver disponível.

Da mesma forma o WhenAny pega uma sequência de tarefas e cria uma tarefa que invoca sua continuação com o primeiro resultado quando qualquer uma das tarefas estiverem finalizadas.

Existirão outras combinações de tarefas e helpers relacionados. Veja mais exemplos no CTP e repare que como não é possível modificar um Task existente os combinadores foram provisóriamente adicionados na classe TaskEx,mas, serão movidos para o Task até a versão final.

Até a próxima!

Artigos Recomendados:

>>   Prepare-se para o C# 5 – Parte 1
>>   Reflection de Alta de Performance
>>   Extension Methods = Manutenibilidade

Nós temos Arquiteto de Software! E arquitetura?

noreply@blogger.com (Apolineo) — Tue, 15 Feb 2011 00:54:00 +0000

O termo arquiteto de software está virando uma commodity dentro das software houses desse meu Brasil.

Esse papel tão importante se apresenta como um diferencial nos serviços prestados aos olhos do cliente e um imenso custo aos olhos da empresa, que sem hesitar, desprezam a idéia de encarar de forma correta o processo de desenvolvimento de software.

Mas, afinal, o que é arquitetura de software?

Bom, a arquitetura de software trata o interesse de 3 visões:

Usuário: como os usuários usarão o sistema?
Negócio: como manter a aplicação flexível e gerenciável?
Sistema: quais os requisitos de performance, internacionalização, segurança e configuração? Quais tendências impactam no design agora ou após a distribuição da aplicação?

O processo de definir estruturas de solução fornece e avalia alternativas de projeto atuando na organização geral de controle, definindo a atribuição de funcionalidade a componentes de projeto, buscando extrair alto desempenho e escalabilidade, sem esquecer claro, de atender requisitos técnicos e operacionais.

O arquiteto de software é o profissional que:

Possui grande compreensão (arriscamos a incluir também “ou facilidade de compreensão”) do negócio e das tecnologias pertinentes para trabalhar na modelagem da solução;
Possui entendimento dos apectos técnicos para o desenvolvimento de sistemas para trabalhar na análise de viabilidade;

Conhece bem as técnicas de levantamento, modelagem e desenvolvimento para trabalhar em provas de conceito, simulações e experimentos;
Entende as estratégias de negócio da instituição onde atua para analisar tendências tecnológicas;

O que é um software bem arquitetado?

Alguns podem dizer que é aquele que faz o que o(s) usuário(s) quer(em). Mas, para avaliarmos se um software está bem projetado temos que identificar os atributos que desejaríamos encontrar nele.

O software bem arquitetado fornece:

E como construímos um software bem arquitetado?

Nosso trabalho começa junto da etapa de levantamento de requisitos buscando identificar:

Peculiaridades de comportamento;
Informações do domínio da aplicação;
Restrições sobre a operação;

A lista abaixo pode ser utilizada como um check-list inicial do que levantar de requisito não-funcional:

Usabilidade
- Facilidade de aprender
- Facilidade de usar
Manutenção
- Reparo
- Evolução
Confiabilidade
- Disponibilidade
- Taxa de falhas
Desempenho
- Tempo
- Espaço
Reusabilidade
- Da aplicação
- Dos subsistemas
- Dos objetos
- Dos módulos
Portabilidade
Segurança
- Disponibilidade
- Integridade
- Confidencialidade
- Operacional

E os complementando estão os atributos do projeto que guiam a concepção de solução para que o produto final satisfaça aos requisitos identificados. Esses atributos são:

Em uma arquitetura podemos identificar os componentes (subsistemas), conectores, mecanismos de interação, topologia e restrições semânticas (por exemplo, a camada de interface só pode acessar dados através da camada de negócios).

O estilo arquitetural, ou o conjunto de padrões, fornecem um conjunto de requisitos não-funcionais e atributos de projeto que permitem distinguir uma arquitetura de outra e prever as características desejadas no sistema.

Os estilos de arquiteturas mais comuns são:

:: CAMADAS

Estruturar o sistema num conjunto de camadas onde cada uma agrupa um conjunto de tarefas num determinado nível de abstração.

vantagem

flexibilidade

desvantagem

alto grau de dependência
performance

:: OBJETOS

Permite a organização do programa em tipos de dados abstratos, que interagem através de troca de mensagens, podem ser modificados, reutilizados, distribuídos e executados sequencialmente ou em paralelo.

vantagem

manutenibilidade
performance

desvantagem

acoplamento
reuso

Atualmente, a combinação de estilos, por exemplo, camadas e objetos, guiam o desenvolvimento de software. A imagem abaixo ilustra a recomendação da Microsoft para a criação de sistemas de informação:

Os atributos que guiam o Microsoft Architecture Guide 2.0 são:

Separação de conceitos: divida as funcionalidades da aplicação (alta coesão) e minimizar pontos de interação (baixo acoplamento);
Responsabiliade única: cada componente deve ser responsável por apenas uma funcionalidade;
DRY (Don’t Repeat Yourself): específique suas intenções em apenas um lugar;
YAGNI (You Ain’t Gonna Neet It): projete apenas o necessário;
LoD (Least Knowledge): um componente ou objeto não deveria conhecer os detalhes internos de implementação

Esperamos que esses conceitos acadêmicos com uma visão prática possam ajudá-lo a vencer os desafios do dia-a-dia.

Na próxima falaremos sobre Arquiteturas de Domínios Específicos (DSSA) e Arquiteturas de Interface com o Usuário.

Até a próxima!

Prepare-se para o C# 5 – Parte 1

noreply@blogger.com (Apolineo) — Tue, 25 Jan 2011 12:58:00 +0000

É fantástico trabalhar com uma plataforma que evolua junto com a complexidade que enfrentamos em nosso dia-a-dia.

Olhando a evolução da linguagem vemos que paramos (ao menos deveriamos ter parado) de escrever certos tipos de código. Por exemplo, com a adição do iterator blocks e do anonymous methods no C# 2.0, o compilador pode armazenar a continuação de “o que vem depois” e encapsular em uma classe os métodos que acessam varíaveis locais.

Com o LINQ e o query comprehensions (C# 3.0) fica a cargo do compilador construir o modelo de objetos correto para construir as chamadas, árvores de expressão e simplifica muito a escrita de código que ordena, filtra, associa, agrupa e sumariza dados.

Hoje em dia vivemos a integração de sistemas. Desenvolvemos aplicativos .NET para rodar dentro de uma rede social em Python. Nossos aplicativos precisam tanto interoperar com sistemas legados quanto sistemas SAP. E para simplificar isso foi criado o dynamic type (C# 4.0), onde fica a cargo do compilador descobrir como gerar o código em tempo de compilação que faça a análise do Dynamic Language Runtime em tempo de execução.

Também estamos utilizando muito algoritmos de programação assíncronos. E a tendência, com sistemas baseados em nuvem, é popularizar esse tipo de algoritmo.

Com o C# 5.0 você será capaz de pegar esse código síncrono:

void ArchiveDocuments(List urls)
{
for(int i = 0; i < urls.Count; ++i) Archive(Fetch(urls[i]));
}

E implementando o FetchAsync e ArchiveAsync transformá-lo em:

async void ArchiveDocuments(List urls)
{
  Task archive = null;
  for(int i = 0; i < urls.Count; ++i)
  {
    var document = await FetchAsync(urls[i]);
    if (archive != null) await archive;
    archive = ArchiveAsync(document);
  }
}

O compilador do C# 5.0 irá gerar o código da máquina de estado, os lambdas, as continuações e checar se a tarefa foi concluída para você. Show!

Esses recursos foram apresentados no último PDC pelo Anders Hejlsberg e atualmente está sendo desenvolvido o CTP do protótipo do compilador do C# 5.0.

Se você se animou com a notícia e quer saber mais visite Asynchronous Programming for C#.

QUE TAL LER A PARTE 2?

Veja também:

>>  Reflection de Alta de Performance
>>  Dynamic CRUD no .NET 4.0
>>  Programação Dinâmica no C# 4.0
>>  Extension Methods = Manutenibilidade

Pensando em ERGONOMIA e USABILIDADE

noreply@blogger.com (Apolineo) — Thu, 06 Jan 2011 13:28:00 +0000

Você já leu um livro onde as páginas não estejam numeradas, sem índice ou resumo? Ou ainda, se sentiu p@#! da vida por procurar uma rua que não tenha placa indicando o nome?

A ergonomia e a usabilidade são constituídos de pequenos detalhes que são notados apenas quando não estão presentes, e estes detalhes ou qualidades, fazem com que os usuários se sintam confiantes e satisfeitos por atingirem seus objetos com menos esforços, em menos tempo e com menos erros.

Programas de software (e até mesmo bibliotecas de código - API) e suas interfaces são ferramentas cognitivas, capazes de modelar representações, abstrair dados e produzir informações, facilitando a percepção, o raciocínio, a memorização e a tomada de decisão para cada tipo de usuário, inteligência, estilo cognitivo e personalidade.

A engenharia de usabilidade surge como resposta a necessidade de desenvolver programas de software interativo com usabilidade.

Enquanto a engenharia de software se preocupa com o núcleo funcional, a estrutura de dados, os algoritmos, os recursos computacionais, a engenharia de usabilidade se preocupa com a lógica de funcionamento, apresentações, estruturas de diálogos e lógica de operação.

Para desenvolvermos uma interface agradável, intuitiva, eficiente e fácil de operar temos que projetar a:

Condução: a inteface deve aconselhar, orientar, informar e conduzir o usuário na interação com o sistema;
Carga de Trabalho: elementos da interface que têm papel importante na redução da carga cognitiva e perceptiva do usuário e no aumento da eficiência do diálogo;
Adaptabilidade: a interface fornece diversas maneiras de realizar uma tarefa, deixando ao usuário a liberdade de escolher e dominar uma delas no curso de aprendizado;
Gestão de Erros: mecanismos que permitem evitar ou reduzir a ocorrência de erros e que favoreçam sua correção caracteriza a interface segura;

Durante toda etapa de desenvolvimento das interfaces deverão avaliadas a ergonomia e a usabilidade da solução proposta buscando identificar:

Barreiras: o usuário esbarra sucessivas vezes e não aprende a transpor sem ajuda externa um aspecto da interface fazendo com que ele desista de utilizar a função do sistema temporária ou definitivamente;
Obstáculos: o usuário esbarra algumas vezes, mas aprende a transpor um aspecto da interface, porém, perde desempenho nas próximas realizações da tarefa;
Ruídos: aspecto da interface que mesmo não sendo barreira ou obstáculo causa uma diminuição de seu desempenho na tarefa.

O aspecto não determinístico do projeto de interfaces sugere que o ciclo de desenvolvimento seja essencialmente evolutivo, iterativo e centrado no usuário (ver DESIGN CENTRADO NO USUÁRIO).

A figura abaixo ilustra esse ciclo:

Os projetistas devem identificar e definir com cuidado os requisitos de usabilidade e, durante o desenvolvimento, certificar-se de que são corretos, assegurar que o protótipo esteja indo na direção correta e que satisfaz tais requisitos antes de ser liberada para implementação ou para o mercado.

Essas abordagens e métodos são iniciativas recentes e efetivas para o desenvolvimento da engenharia de usabilidade e certamente o ajudará nos desafios diários.

MOSTRE A TODOS OS CONCEITOS APRENDIDOS PARTICIPANDO DO QUIZZ “PENSANDO EM ERGONOMIA E USABILIDADE”.

Gostou? Siga-nos e compartilhe suas experiências e opiniões deixando seu comentário.

Posts Relacionados

Design centrado no usuário

noreply@blogger.com (Apolineo) — Mon, 15 Nov 2010 18:36:00 +0000

Atualmente o design tem recebido uma atenção especial, visto que, além de ser o conjunto que é percebido pelo usuário, ele também pode significar redução de custos de treinamentos e manuais.

Pesquisando na internet sobre o assunto encontramos uma video aula de um curso de iPhone da Stanford sobre "How to Build an iPhone App that Doesn’t Suck! (In 10 Easy Steps)" do Steve Marmon (@marmon). Ele menciona 10 passos para se desenvolver aplicativos que não sejam “um lixo”. Porém, estes passos podem ser aplicados para quase qualquer projeto. Os passos comentados, estão a seguir:

1. Decida o que construir (Decide what to build)

Muitas vezes pensamos em uma solução levando em conta apenas necessidades secundárias, ou seja, aquelas que nos guiam a atender desejos e não o real problema que estamos nos propondo a resolver. Dessa forma, corremos o risco de não solucionar nenhum problema, ou ainda, de desenvolvermos uma solução ineficaz.

Para não cair nessa armadilha, procure enteder qual problema estamos nos propondo a resolver, pra quem estamos projetando e os tenhamos em mente ao desenvolver a solução. Focar em um grupo específico aumenta a chance de sucesso, pois o feedback desses usuários será de útil para melhorarmos o produto e conquistarmos os clientes.

Se o seu software for um produto interno, envolva os usuários finais (ou pessoas chave que representem e entendam as necessidades desses usuários), agora, caso seja um produto para o mercado, ou seja, você não tem como envolver o usuário, procure fazer pesquisas (faixa etária, classe social, nível de escolaridade, etc) para identificar bem as necessidades e guiar o desenvolvimento da interface do produto.

Conheça as personas.

2. Visite a app store (Visit the app store)

No mundo globalizado um produto inovador pode ser a composição de idéias brilhantes de produtos similares ou não, portanto, observe como aplicativos similares resolveram problemas que você está se propondo a resolver.

Eles já devem ter tido feedback de usuários e alterado o produto em função disso, e você, estará "recebendo" estes feedbacks gratuitamente.

Se existirem concorrentes, faça um benckmarking e compare as vantes e desvantagens em relação ao seu produto.

3. Explore as possibilidades de soluções (Explore possible solutions)

A primeira solução não é a única e tampouco a melhor!

Trabalhe com as limitações e aproveite os padrões para conseguir, com mais algumas tentativas, encontrar a solução ideal.

4. Rabisque (Sketch)

Para ter uma boa idéia, tenha várias, procure designs alternativos para o mesmo problema, faça várias propostas de solução!

Com 10 propostas, por exemplo, sua chance de ter algo realmente bom é muito maior. É assim que a Apple funciona. É assim que a IDEO funciona.

Rabisque e comunique suas idéias.

5. Construa um protótipo de papel (Build a paper prototype)

Um vício de longa data da área de desenvolvimento de softare e sair para a programação ou o design sem antes criar um protótipo, e quando ele é feito, a única preocupação é com relação aos campos que tem que ter.

Hoje há mais itens a ser levado em consideração, e aproveite que nesta fase, o custo de alteração é muito baixo. Pense, quanto tempo você gasta para alterar uma página no protótipo? E para reprogramar uma tela? Apresente o protótipo para pessoas chaves, analise suas reações, colha feedbacks e veja se o caminho que você está tomando é o correto.

"Fail early to succeed sooner".

6. Abra o omnigraffle (Fire up omnigraffle)

Aqui ele fala do omnigraffe para o caso específico do iPhone, porém, a mensagem é para que use uma ferramenta que permita criar um protótipo (Sketchflow?). Este protótipo será esteticamente parecido com a versão final, mas sem precisar gastar tempo programando.

A idéia é a mesma da etapa anterior, permitir alterações sem elevar o custo.

7. Faça tudo denovo (Do it all again)

Já ouviu a frase "A melhor época de começar uma faculdade é quando se termina"? Isso quer dizer que, quando terminamos os estudos é que descobrimos o que precisavamos aprender.

Sendo assim, como todo design centrado no usuário, a parte mais importante do processo é iterar. Veja onde está com problemas, volte, questione se a solução dada é a melhor para aquele caso e pense em várias alternativas de correção para o problema encontrado.

Prototipe antes de alterar, teste e siga assim até que o produto esteja estável.

8. Agora você pode programar (Okay, you can code finally)

Agora pode partir para a programação do seu produto.

Use padrões de design e programação como MVC, que possibilitem alterações futuras sem muito trabalho, desvinculando o código da parte visual/apresentação.

9. Abra seu aplicativo para beta testers (Beta test your app)

Utilize os testes para levantar os bugs que passaram desapercebidos pelos testes em protótipos e pelos programadores, como bugs relativos à satisfação dos usuários.

Um exemplo, no iPhone, pode ser a rolagem da tela estar muito "lerda". Os programadores vão achar que a tela está excelente, porque está rolando, porém os usuários, após algum tempo de uso, se sentirão incomodados com isso.

O Tweetie foi o primeiro app de twitter a conseguir uma rolagem rápida, e teve grande destaque por conta disso.

10. Lance (Release)

Se você fez tudo direito, este será um momento feliz e de boas noites de sono, senão, prepare-se para os problemas que virão (e-mails de bugs, reclamações, comentários negativos sobre o aplicativo, etc.).

Bem vindo ao mundo moderno do design!

Compartilhe suas idéias conosco e até a próxima!

Reflection de Alta de Performance

noreply@blogger.com (Apolineo) — Tue, 09 Nov 2010 21:26:00 +0000

Pesquisando no Google vemos alguns bons artigos explicando que Reflection é lento. Está certo, alguns métodos do Reflection, como GetXXX (do MethodInfo, PropertyInfo, FieldInfo, etc.), são cerca de 100 vezes mais lento que acessar diretamente uma propriedade ou executar um método.

O quanto o Reflection é lento?

Vamos criar um pequeno exemplo para analisarmos a performance do Reflection. Esse exemplo terá uma classe simples que contém apenas 1 método:

namespace CustomNamespace

{

public interface ICustom

{

void CallMe(int x);

}

public class CustomClass : ICustom

{

public void CallMe(int x)

{

x = x + 10;

return;

}

Simples, não? Bom, vamos criar uma classe para consumir e checar a performance em situações de extress. Vamos criar objetos do tipo CustomClass em um loop e executar o método CallMe com valores randomicos de duas formas: 1. Sem Reflection, 2. Com Reflection

Para o teste com Reflection, vamos criar uma classe (ReflectionCalculator) com alguns métodos:

public partial class ReflectionCalculator

{

private Type dummyType;

public Type DummyType

{

get

{

dummyType = dummyType ??

CurrentAssembly.GetType("CustomNamespace.CustomClass",

true,

true);

return dummyType;

}

private MethodInfo method;

public MethodInfo Method

{

get

{

this.method = this.method ??

this.DummyType.GetMethod("CallMe", BindingFlags.Instance |

BindingFlags.Public, null, new Type[] { typeof(int) },

null);

return this.method;

}

private object dummyObject;

public object DummyObject

{

get

{

if (this.dummyObject == null)

{

dummyObject = Activator.CreateInstance(this.DummyType);

}

return dummyObject;

}

public void ReflectionBasedCall(int value)

{

this.Method.Invoke(this.DummyObject, new object[] { value });

}

public void NormalCall(int value)

{

this.MyClass = this.MyClass ?? new CustomClass();

this.MyClass.CallMe(20);

}

Então, se olhar para as duas chamadas ReflectionBasedCall e NormalCall verá que ambos fazem a mesma coisa. A abordagem de reflexão deve primeiro obter um Type usando Assembly.GetType (que evetualmente vasculha toda a hierarquia do objeto inteiro) e depois o GetMethod no tipo encontrado. Portanto quanto maior o tamanho do Assembly mais lento será. Por fim, usamos o Activator.CreateInstance para criar a instância do objeto.

Agora, e se executassemos os métodos 1.000.000 de vezes usando esse código e imprimissemos o tempo em segundos, ele irá se parecer com:

static void Main(string[] args)

{

var watcher = new System.Diagnostics.Stopwatch();

var calculator = new ReflectionCalculator();

watcher.Start();

for (int i = 0; i < 1000000; i++)

{

calculator.NormalCall(i);

}

watcher.Stop();

Console.WriteLine("Time Elapsed for Normal call : {0}",

watcher.Elapsed.TotalSeconds);

watcher.Reset();

watcher.Start();

for (int i = 0; i < 1000000; i++)

{

calculator.ReflectionBasedCall(i);

}

watcher.Stop();

Console.WriteLine("Time Elapsed for Reflection call : {0}",

watcher.Elapsed.TotalSeconds);

Console.ReadLine();

}

Abaixo, a saída da execução:

Reflection + Lambda Expression = Dynamic Delegates

Na versão 3.0 do Microsoft .Net Framework, juntamente com o Linq, foi introduzido o Lambda Expression, que é uma função anonima que pode conter expressões e funções e pode ser usada para criar Delegates ou tipos de árvores de expressão.

Criar delegates em runtime é atualmente a melhor maneira de fazer o código Reflection ser executado muito rápido. A idéia básica é criar delegates de cada MethodInfo que precisamos executar e eventualmente fazer cache dele em memória.

Para isso, precisamos construir um Action<> (no caso de método VOID) ou Func<> (no caso de método que retorne algo) para cada método:

public static Action<object, T> CallMethod(this MethodInfo methodInfo)

{

if (!methodInfo.IsPublic) return null;

var returnParameter = Expression.Parameter(typeof(object), "method");

var valueArgument = Expression.Parameter(typeof(T), "argument");

var setterCall = Expression.Call(Expression.ConvertChecked(returnParameter,

methodInfo.DeclaringType),

methodInfo,

Expression.Convert(valueArgument, typeof(T)));

return Expression.Lambda<Action<object, T>>(setterCall, returnParameter,

valueArgument).Compile();

}

A expressão lambda acima cria um delegate do tipo Action onde “object” representa a instância da classe no qual executaremos o método e “T” representa o tipo do argumento do método. O código acima cria uma expressão:

(x, y) = return x.[method](y)

Com isso, podemos guardar na memória a referência construída dinamicamente:

private MethodInfo methodInfo;

public MethodInfo CachedMethodInfo

{

get

{

this.methodInfo = this.methodInfo ?? this.GetMethodInfo();

return this.methodInfo;

}

private MethodInfo GetMethodInfo()

{

Type myClass = this.CurrentAssembly.GetType("CustomNamespace.CustomClass",

true,

true);

return myClass.GetMethod("CallMe", BindingFlags.Instance |

BindingFlags.Public, null, new Type[] { typeof(int) }, null);

}

private Action<object, int> _methodcallDelegate = null;

public Action<object, int> MethodCallDelegate

{

get

{

this._methodcallDelegate = this._methodcallDelegate ??

this.CachedMethodInfo.CallMethod<int>();

return this._methodcallDelegate;

}

Vamos executar o código de teste mais uma vez para ver o quão eficiente é essa técnica:

Veja que a diferença em relação a uma abordagem hard-coded caiu drasticamente expandindo as possibilidades de criação de algoritmos genéricos e de alta performance.

Você tem dicas e truques? Compartilhe! Envie para social@apolineo.com.br que colocaremos no blog.

Fique a vontade também de enviar suas sugestões e críticas.

Download: Código Fonte

Até a próxima!

Boas práticas para gerência de requisitos, de acordo com os modelos MPS.BR e CMMI

noreply@blogger.com (Apolineo) — Mon, 04 Oct 2010 01:18:00 +0000

A atividade de gerência de requisitos tem por objetivo mapear os requisitos identificados na fase inicial de um projeto e rastreá-los até os artefatos finais, permitindo a validação da consistência entre os mesmos e as requisições originalmente vindas dos solicitantes, conforme definido pelo modelo CMMI [SEI, 2006].

No entanto, [SOMMERVILLE, 2007] ressalta o fato de que os requisitos de sistema mudam constantemente, em virtude do amadurecimento na compreensão das pessoas envolvidas acerca do que desejam que o software faça ou ainda de modificações no hardware, software ou ambiente organizacional do sistema.

Deste modo, um controle efetivo dos requisitos vindos do usuário e de suas mudanças, assume papel maior que simplesmente atender a especificação de uma área de processo e sim de garantir a adequação do produto final ao seu meio externo.

A gerência de requisitos representa assim, a figura de ligação entre as áreas de planejamento de projeto, solução técnica e gerência de configuração. Um reflexo disso é o fato de que este é um dos processos que não aceitam qualquer exclusão no modelo MPS.BR [SOFTEX, 2008].

Sendo fundamental a ambos os modelos de referência, esta área de processo recebe enfoques semelhantes em cada um deles. Porém ambos apresentam apenas listas de necessidades que devem ser atendidas e não uma proposta de artefatos para sua realização.

Deste modo, empresas que tenham interesse em melhorar seus processos precisam buscar referências externas a respeito de como proceder, gerando margem para implementações custosas e pouco eficientes daquilo que deveria ser uma otimização de processos.

Este artigo tem por objetivo apresentar uma contextualização entre o processo de gerência de requisitos e as necessidades impostas pelos modelos CMMI e MPS.BR, definindo um conjunto mínimo de artefatos para cumprimento das mesmas, que possam ser utilizados por empresas de pequeno ou médio porte.

São descartadas neste artigo as necessidades referentes à área de processo de definição de requisitos – formalizada em [SEI, 2006] - uma vez que a mesma não é o
foco deste estudo.

Modelos de Referência

Dentre os diversos modelos propostos ao redor do mundo, foram selecionados os modelos de referência CMMI e MPS.BR, sendo o primeiro selecionado por sua aceitação mundial e representatividade de mercado, enquanto o segundo representa um movimento que propõe uma aproximação ao cenário das empresas brasileiras.

O modelo de referência para melhoria de software brasileiro (MR-MPS) indica ainda uma equivalência [SOFTEX, 2008] entre seus processos e as áreas de processo definidas no modelo CMMI, conforme ilustra a abaixo.

CMMI e a Gerência de Requisitos

Dentro do modelo CMMI, a gerência de requisitos é uma área de processo componente do Nível 2 de Maturidade, conhecido como “Gerenciado”. Neste nível, os processos da empresa devem ser executados dentro de um padrão e por pessoas habilitadas, de acordo com controles definidos [SEI, 2006].

A gerência de requisitos tem aqui o papel de garantir que todos os artefatos produzidos sejam coesos com a necessidade do cliente, por meio da identificação dos requisitos que originaram cada implementação. É vista também como ponto de partida para o planejamento de atividades e entregas, uma vez que a área de gerência de configuração pode definir seus pacotes em virtude de agrupamentos de requisitos.

Outro aspecto relevante é a possibilidade de rastrear o impacto na solução de falhas no software ou nas solicitações de mudanças vindas dos usuários.

MPS.BR e a Gerência de Requisitos

Diferentemente do CMMI, dentro do modelo MPS.BR, o processo de gerência de requisitos é visto como parte do nível mais baixo de maturidade possível, o Nível G, conhecido como “Parcialmente Gerenciado” [SOFTEX, 2007].

Este enfoque coloca um maior destaque nas tarefas que deste processo, colocando-o num papel de ligação entre artefatos e requisitos, objetivando que a rastreabilidade com relação às necessidades originalmente mapeadas seja mantida. Trata-se então de uma diferença sutil, que demanda atenção extra às tarefas que o
compõe.

Com relação à avaliação de impacto em solicitações de mudanças ou correções de falhas, a definição é similar ao proposto pelo CMMI.

A Questão da Rastreabilidade

Uma das exigências comuns ao nível G do MPS.BR e ao nível 2 do CMMI é a rastreabilidade entre um requisito e todos os artefatos envolvidos na implementação
decorrente dele, conforme apresentado em [SEI, 2006] e [SOFTEX, 2007].

Esta prática permite uma maior efetividade na gerência de configuração, que visa justamente garantir que cada versão do software permita isolar uma versão compatível dos componentes envolvidos em sua realização, chamada baseline. Realizar
esta tarefa sem uma referência sólida a quais telas ou componentes são afetados por
determinado requisito, dificultaria a tarefa de isolar a versão, inviabilizando a geração de baselines.

No entanto, este rastreio se complica quando consideramos que um requisito pode ser atendido por uma tela inteira ou por uma simples caixa de texto. [MEDEIROS, 2006]

Levando em conta que um documento de caso de uso pode ser utilizado para refletir uma tela ou um único método, desde que este seja suficientemente relevante, tem-se uma opção se solução: mapear casos de uso versus requisitos funcionais.

Por meio desta prática é possível identificar no detalhe os artefatos que serão afetados cada vez que uma mudança é realizada em um caso de uso específico, bem como prover uma análise de impacto mais eficaz antes de planejar uma tarefa.

A elaboração de uma planilha descrevendo esta relação, em conjunto à existência de um documento padronizado para a elicitação de requisitos, onde seja possível não apenas mapear as necessidades, mas também a interdependência entre requisitos (sejam
eles funcionais ou não) permite atender a todas as necessidades especificadas pelos modelos CMMI e MPS.BR, conforme descrito em seus documentos de referência.

Artefatos para a Gerência de Requisitos

Levando em conta os aspectos discutidos anteriormente, propõe-se que a gerência de requisitos seja atendida por meio da adoção de artefatos que reflitam tarefas consideradas padrão de mercado, no que diz às atividades realizadas pelos envolvidos
em sua realização.

Os documentos propostos são: Documento de Visão, Matriz de Rastreabilidade e Documento de Especificação de Caso de Uso, compatíveis com o Rational Unified Process [RATIONAL, 2009], processo de engenharia de software que se baseia na definição de disciplinas para atribuição de tarefas e responsabilidades no desenvolvimento do software.

Visando atender os modelos de referência observados, é necessário que os artefatos possuam sessões específicas para mapeamento das relações de dependência com os diversos requisitos elicitados, conforme definido. Cada um destes artefatos acompanha todo o ciclo de vida do desenvolvimento do software, permeando suas diferentes fases. A seguir, cada um deles será observado em mais detalhes, bem como a relação entre artefatos, usos e fases do ciclo de vida.

Por meio deles, as cinco práticas específicas exigidas pelo CMMI são totalmente atendidas, bem como os cinco resultados esperados propostos melo MPS.BR.

Documento de Visão

Um documento relacionando as necessidades do usuário, seu entendimento por parte do analista de requisitos e o conjunto de requisitos (funcionais ou não) propostos para atender cada uma das necessidades mapeadas. Este documento é validado pelos usuários e pode ser utilizado para definição do escopo inicial do projeto.

Fases do Ciclo de Desenvolvimento em que é empregado e atividades realizadas:

Pré-Venda: Análise do Problema, Definição de Requisitos de Negócio e Requisitos de Usuário, Definição de Requisitos Funcionais e Requisitos Não Funcionais;
Análise e Design: Relação entre: Requisitos de Usuário e Requisitos de Negócio, Requisitos de Negócio e Requisitos Não Funcionais, Requisitos de Usuário e Requisitos Funcionais.

Práticas Específicas do CMMI atendidas [SEI, 2006]:

SP 1.1. Obter um entendimento dos requisitos;
SP 1.2. Obter aprovação dos requisitos.

Resultados Esperados do MPS.BR atendidos [SOFTEX, 2007]:

GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;
GRE 2. Os requisitos de software são aprovados utilizando critérios
objetivos.

Matriz de Rastreabilidade

Documento responsável por estabelecer uma relação bidirecional entre os requisitos originais e os componentes do produto final (software). Caso um requisito não possua nenhum caso de uso equivalente mapeado na planilha, uma inconsistência de projeto é efetivamente localizada.

Fases do Ciclo de Desenvolvimento em que é empregado e atividades realizadas:

Análise e Design: Relação entre Casos de Uso e Requisitos Funcionais;
Validação e Homologação: Possibilita o Rastreio e comparação entre uma implementação e a necessidade que a originou.

Práticas Específicas do CMMI atendidas [SEI, 2006]:

SP 1.3. Gerenciar as mudanças de requisitos;
SP 1.4. Manter rastreabilidade bidirecional entre os requisitos;
SP 1.5. Identificar inconsistências entre projeto e requisitos.

Resultados Esperados do MPS.BR atendidos [SOFTEX, 2007]:

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida;
GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos;
GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.

Documento de Especificação de Caso de Uso

Além do tradicional Diagrama de Casos de Uso, cabe elaborar um documento detalhando cada caso de uso, de acordo com sua especificidade [MEDEIROS, 2006]. Neste documento é realizada a especificação da implementação que será realizada pelos desenvolvedores, já com o foco nos artefatos que serão produzidos.

Embora esteja muito mais relacionado à área de processo de definição de requisitos do que à gerência propriamente dita, sua realização é essencial à construção da Matriz de Rastreabilidade, que vincula os casos de uso a seus requisitos.

Fases do Ciclo de Desenvolvimento em que é empregado e atividades realizadas:

Análise de Design: Detalha a solução para uma necessidade traduzida em requisito funcional e permite a validação da solução proposta pelo Analista de Requisitos ou de Negócio.

Práticas Específicas do CMMI atendidas [SEI, 2006]:

SP 1.4. Manter rastreabilidade bidirecional entre os requisitos.

Resultados Esperados do MPS.BR atendidos [SOFTEX, 2007]:

GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida.

Conclusão

Por meio da utilização de três artefatos de confecção relativamente simples – Documento de Visão, Matriz de Rastreabilidade e Documento de Especificação de Caso de Uso - é possível atender a todas as exigências estabelecidas à área de processo de Gerência de Requisitos, de acordo com os modelos de referência analisados.

Porém, o nível de interdependência entre os documentos evidencia a necessidade de um processo eficiente para a definição dos requisitos, uma vez que uma falha nesta atividade resultará em um conjunto inconsistente de requisitos no documento de visão, refletidos em casos de uso que não traduzem a real expectativa do cliente.

Estes casos de uso e requisitos serão relacionados na matriz de rastreabilidade e futuramente, quando forem recebidas solicitações de mudanças em determinados pontos do sistema, a tarefa de localizar o ponto de origem do problema e os demais casos de uso relacionados a este mesmo requisito terá sua complexidade incrementada.

Outra questão que se torna evidente é a margem de falha humana, pois ao discutir a elaboração dos referidos artefatos sem a proposta de um pacote especializado de ferramentas surge a possibilidade de que determinado campo não seja preenchido, mesmo que de forma não intencional. Deste modo, cabe a cada empresa avaliar a relação entre custo e benefício da adoção de meios automatizados para a construção e relacionamento dos documentos.

É interessante ressaltar também que o modelo MPS.BR prega compatibilidade com o CMMI e, no que diz respeito à gerência de requisitos, seus resultados esperados correspondem diretamente às práticas específicas impostas pelo modelo norteamericano, de modo que os artefatos propostos poderiam ser elaborados considerando apenas o CMMI como critério de satisfação.

No anexo você encontra modelos de documentos ilustrando os conceitos abordados: Gerencia_Requisitos_slides.pdf

Referências Bibliográficas
[SEI, 2006] CMMI Product Team. CMMI for Developmment, Version 1.2. Pittsburg, EUA: Carnegie Mellon University – Software Egineering Institute, 2006.

[SOMMERVILLE, 2007] Sommerville, Ian. Engenharia de Software, 8ª Edição. São Paulo: Pearson Addison Wesley, 2007.

[SOFTEX, 2008] FAQ Implementação MR-MPS - Dúvidas sobre o Guia Geral e Guia de Implementação. http://www.softex.br/mpsBr/_faq/faqImplementacao.asp.
Recuperado em 01/12/2008.

[SOFTEX, 2007] Associação para Promoção da Excelência do Software Brasileiro - SOFTEX. MPS.BR – Guia Geral, Versão 1.2, junho 2007.

[MEDEIROS, 2006] Medeiros, Ernani Sales de. Desenvolvimento de Software com
UML 2.0: definitivo. São Paulo: Pearson Makron Books, 2006.

[RATIONAL, 2009] Technical resources and best practices for the Rational® software
platform. http://www.ibm.com/developerworks/rational. Recuperado em 03/02/2009.

Autor: Ângelo Amaral
Sobre: Pós-graduado em Engenharia de Software pelo ITA com especialização em modelos de construção de aplicações comerciais utilizando motores de regras de negócio, possui experiência na implantação de scrum e coordenação de projetos e sistemas de varejo.
Contato: angelo.amaral@gmail.com

Dynamic CRUD no .NET 4.0

noreply@blogger.com (Apolineo) — Thu, 09 Sep 2010 01:10:00 +0000

No último artigo fizemos um overview sobre programação dinâmica e as possibilidades que ela oferece, e terminamos, com uma idéia sobre um CRUD a partir do banco. Hoje veremos como isso poderia ser feito.

A idéia é usarmos o DLR (Dynamic Language Runtime) para que nosso código compilado ignore a estrutura estática dos tipos que podem ser detectados na compilação, ou seja, ter a verificação de tipos somente no momento da execução. Dessa forma, vamos até o momento de dados, obtemos o schema da tabela que desejamos e criamos a estrutura de um objeto correspondente a ela. Depois disso, montamos a rotina para inserção de registros na base (na tabela ao qual a entidade se refere) e criamos na entidade o método que executa esse rotina.

Para que tudo isso seja possível precisamos conhecer o intermediario de toda essa “mágica”, portanto, lhes apresento o “ExpandoObject”.

A classe ExpandoObject pertence ao namespace System.Dynamic e é definida no assembly System.Core e representa um objeto cujos membros podem ser dinamicamente adicionados e removidos em tempo de execução.

public sealed class ExpandoObject :
    IDynamicMetaObjectProvider,
    IDictionary<string, object>,
    ICollection<KeyValuePair<string, object>,
    IEnumerable<KeyValuePair<string, object>>,
    IEnumerable,
    INotifyPropertyChanged

Na verdade, é a interface “IDynamicMetaObjectProvider” quem permite que um objeto seja compartilhado no DLR (Dynamic Language Runtime) por programas escritos de acordo com o modelo de interoperabilidade DLR, ou seja, apenas os objetos que implementam essa interface podem ser compartilhados em linguagens dinâmicas do .NET.

Dynamic CRUD

A idéia aqui é criarmos um objeto contendo todas as propriedades da tabela e os métodos do CRUD (do Inglês Create, Read, Update e Delete), porém, por questões de simplicidade, nosso exemplo focará apenas na inserção de dados (Create).

A figura abaixo representa a estrutura que criaremos:

O grande astro dessa solução é classe “Entity”, que é a responsável por criar uma instância e adicionar as propriedades (de acordo com as colunas do banco) e o método de inclusão de dados.

O primeiro passo é criar uma instância de “ExpandoObject”, da mesma forma que qualquer outro objeto .NET, exceto pelo fato de que a variável para armazenar a instância é do tipo “dynamic”.

dynamic entity = new ExpandoObject();

Após buscarmos o schema da tabela na base de dados vamos adicionar as propriedades, e para isso, você apenas atribui a ela um novo valor, por exemplo:

entity.ExpandoEntityName = name;

Porém, não sabemos o nome das propriedades, afinal, os recuperamos a partir do schema da tabela, como fica?

Lembra que o “ExpandoObject” implementa a interface “IDictionary”? Então, é a parte “string” ou “key” é o nome da propriedade ou método, e a parte “object” ou “valor”, é valor da propriedade ou o delegate do método. Sendo assim, convertemos nosso “ExpandoObject” para “IDictionary” e através de um loop criamos todas as propriedades:

var e = (entity as IDictionary<string, object>);
foreach (var property in propertyList)
{
e[property.Name] = "";
}

O mesmo serve para a criação do método de inserção:

entity.Insert = new Action(() => {
SqlClientPlugin.Insert(tableName, entity, propertyList);
});

O uso dessa estrutura nos permitiria criar um código assim:

var company = Entity.NewEntity("Teste");

company.Name = "Apolineo Serviços de Informática Ltda.";
company.WebSite = "http://www.apolineo.com.br";

company.Insert();

Bom, isso é só uma possibilidade de uso de programação dinâmica e esperamos que sirva de estopim para outras grandes idéias de uso.

O código de exemplo pode ser obtido no link abaixo:
ExpandoObjetoTestSolution.rar

Até a próxima!

Programação Dinâmica no C# 4.0

noreply@blogger.com (Apolineo) — Mon, 16 Aug 2010 11:38:00 +0000

A programação com a plataforma Microsoft .NET Framework se baseia na programação com tipos de dados estáticos, ou seja, toda expressão é de um tipo conhecido no momento da compilação e possíveis erros são conhecidos com antecedência.

Ao usar reflexão você pode resolver dependências de tipo em tempo de execução e habilitar seu código para funcionar baseado em uma interface sem ter que saber o tipo concreto, e essa técnica, usada desde a versão 1.0 do .NET Framework, foi amplamente utilizada para criar estruturas IoC (Inverse of Control – Insersão de Controle). Porém, apesar da flexibilidade, a interface do objeto de destino é fixa e imutável, ou seja, sempre existe uma interface conhecida por trás de qualquer chamada realizada através da reflexão.

O .NET Framework 4.0 tráz novos recursos que lhe permitirão ir além dos tipos estáticos. A tipificação dinâmica atrasa qualquer verificação de tipo até o momento da execução, ou seja, ignora a estrutura estática dos tipos no momento da compilação.

Com objetos dynamic, é possível definir a interface do objeto de maneira programática e ter a clareza formal de objetos estáticos e a flexibilidade dos tipos dinâmicos.

Com essa técnica é possível implementar um CRUD a partir do schema do banco de dados, criar um ponto de acesso centralizado para atender solicitações de requisições de interfaces com o usuário e fazer o tratamento necessário (navegação, integrar com serviços de negócios, etc) através de uma string (ASP.NET MVC? AJAX?), estruturar em objetos um XML, enfim, as possibilidades são muitas e a criatividade é o limite.

No próximo artigo apresentarei falaremos de objetos Expando e mostrei a idéia do CRUD a partir do schema do banco.

Até mais!

Extension Methods = Manutenibilidade

noreply@blogger.com (Apolineo) — Wed, 14 Jul 2010 18:40:00 +0000

Com a versão 3.0 do .Net Framework tivemos, dentre outros recursos, a introdução do Extension Method, que é uma técnica para adicionar comportamento (método) a um determinado tipo sem a necessidade de alterar o código original ou criar tipos derivados.

Uma boa estratégia de uso de métodos de extensão contribui para um a manutenibilidade, que é um aspecto da qualidade de software que se refere ao esforço necessário para diagnosticar deficiências ou causas de falhas, ou localizar as partes a serem modificadas para corrigir os problemas ou à facilidade de modificação ou adaptação, ao esforço necessário para realizar alterações ou para adequar o produto a eventuais mudanças de ambiente operacional.

Imagine um método, em uma classe de negócio, que realiza o a venda de um produto e da baixa no estoque:

if (IsValid(sale) && AllItemsAreValids(sale.SaleDetailsList))

{

    var products = VerifyProductStockAvailability(sale);

    using (var trans = new DataTransaction())

    {

        var daoSale = new DAOSale();

        var daoProduct = new DAOProduct();

        daoSale.Insert(sale);

        for (int i = 0; i < sale.SaleDetailsList.Count; i++)

        {

            daoSale.InsertDetail(sale.SaleDetailsList[i]);

        }

        for (int i = 0; i < products.Count; i++)

        {

            daoProduct.UpdateStock(products[i]);

        }

        trans.Complete();

    }

}

Refatorando o código, aplicando métodos de extensão e buscando uma melhor lêxia do código, podemos chegar em resultados como:

if (sale.IsValid() && sale.SaleDetailsList.HasAllItemsValid())

{

    var products = VerifyProductStockAvailability(sale);

    using (var trans = new DataTransaction())

    {

        sale.Insert();

        products.UpdateStock();

        sale.SaleDetailsList.Insert();

        trans.Complete();

    }

}

Muitos podem argumentar que a diferença é pouca, o código é legível e de boa manutenibilidade das duas formas, eu concordo, porém, na segunda ele é muito mais fácil e rápido para ler e entender, além de que, com o uso dos métodos de extensão introduzimos um nível a mais de abstração.

Um recurso simples, porém, poderoso!

Como você o utiliza em seus projetos? Deixe seu comentário.

Até a próxima!

Validação, Verificação e Testes de Software

noreply@blogger.com (Apolineo) — Mon, 12 Jul 2010 20:22:00 +0000

Qualidade não é um diferencial de mercado para as empresas conseguirem vender mais e lucrar mais, hoje, é um pré-requisito que devem conquistar para conseguir colocar seus produtos no mercado global.

Para obter qualidade, devemos, por exemplo, estar em conformidade com requisitos de clientes, antecipar-se e satisfazer os desejos dos clientes, ou ainda, escrever tudo o que se deve fazer e fazer tudo o que foi escrito.

E o que leva a falta de qualidade? A inabilidade de um software em cumprir a especificação de requisitos operacionais de sua responsabilidade, ou a habilidade de produzir efeitos indesejados são chamados de FALHAS (FAIL) e são a manifestação física (ERROR) de um DEFEITO (FAULT – imperfeição ou anomalia existente no código-fonte de um programa), o que a produtos pouco confiaveis, ou seja, de baixa qualidade.

O teste de software é um conjunto de atividades que pode ser planejada antecipadamente e realizada sistematicamente, ou seja, consiste num estudo das fases do software (desde a análise até a entrega do produto). Existem dois tipos de atividade: A verificação, que faz com que o software funcione corretamente de acordo com especificações; e a validação, que se refere ao conjunto de atividades que garantem ao software construído funcionar de maneira razoável de acordo com as exigências do cliente.

A figura abaixo ilustra quando testar, como testar e o que testar:

Esperamos que esse tipo de informação lhe seja útil no momento de avaliar como garantir ou melhorar a qualidade dos software feitos.

Até a próxima!

Alinhamento Estratégico de TI – Parte 3

noreply@blogger.com (Apolineo) — Fri, 25 Jun 2010 19:39:00 +0000

Nessa série de artigos buscamos avaliar como as empresas de tecnologia de organizam para competir e obter sucesso nesse acirrado mercado, além de, fazer uma análise para guiar a estratégia de competitividade.

Numa análise horizontal da área de software temos que:

Dessa forma, vamos abordar nosso útimo modelo de processo de desenvolvimento de software, o modelo orientado a produtos.

Esse tipo de modelo possui como característica o desenvolvimento e suporte de produtos de software (software pacote, ferramenta de desenvolvimento, componentes e produtos complexos) e tem na programação (design patterns), no design (arquitetura) e nos testes de sistema suas atividades principais, além de, foco de qualidade no produto.

Com isso, o gerenciamento do projeto deve se concentrar na duração do projeto (seu maior risco) e na qualidade do produto. O modelo ISSO 9126 deve ser o referencial para esse tipo de empresa.

E não precisamos nem dizer que inovações no produto é o fator chave para o sucesso.

Esperamos que essas informações sejam utéis a você tanto quanto tem sido para nós.

Agradecimentos especiais ao André Leme Fleury por essa brilhante análise.

Até a próxima!

Alinhamento Estratégico de TI – Parte 2

noreply@blogger.com (Apolineo) — Tue, 22 Jun 2010 02:19:00 +0000

No artigo anterior apresentamos alguns fatores que empresas que projetam, desenvolvem ou implementam sistemas de software específicos (customizados), ou seja, orientados a clientes deveriam considerar para se diferenciar.

Hoje abordaremos o modelo de processo de desenvolvimento de software para empresas que possuem uma quantidade razoável de clientes e customizações de produtos.

Esse tipo de empresa tem como caracterísca serviços relacionados com customização, treinamento ou operação de software e tem como principais atividades a programação e a modelagem de sistemas. Seu foco é em pesquisa e desenvolvimento de um portfólio de serviços, que basicamente é composto por:

• Customização (fábrica de software)
• Implantação
• Treinamento
• Outsourcing

Para esse tipo de empresa, orientada a serviços, o fator chave para o sucesso é a gestão do projeto de acordo com as especificações contratuais e seu maior risco é o custo e a duração do projeto. Portanto, um foco de qualidade baseado em projeto e fundamentado no PMBok são muito importantes para o sucesso comercial da empresa.

Seu business é serviço? Think ahead!

No próxima, e último, falaremos sobre empresas de produtos.

Até mais!

Alinhamento Estratégico de TI – Parte 1

noreply@blogger.com (Apolineo) — Thu, 10 Jun 2010 01:06:00 +0000

A atividade principal da sua empresa é tecnologia? Como ela se organiza para competir no mercado?

Investir em metodologia, arquitetura, gestão, treinamento, etc, são importantes para todas as empresas, porém, dependendo do posicionamento de mercado da sua empresa alguns pontos são mais importantes que outros.

Hoje, vamos discutir sobre empresas que projetam, desenvolvem, implementam sistemas de software específicos (customizados), ou seja, orientadas a clientes.

Por que orientadas a cliente? Porque, os produtos/serviços são sistemas de acordo com especificações do cliente e o fator chave para o sucesso é atender e superar as expectativas do cliente. Com isso, o principal ponto da gestão do projeto é gerenciar as expectativas do cliente e as mudanças nos requisitos do projeto (o principal risco).

Esse tipo de empresa deveria ter como estratégia competitiva a excelência operacional através de um processo de produção otimizado (por exemplo, baseado no CMMI), pois quanto mais otimizado o processo, maior a previsibilidade e produtividade da produção de um produto customizado.

Sua empresa se enquandra nesse perfil?

Na próxima falaremos sobre empresas de serviços.

Até mais!

Pare. Identifique o Problema. Avalie Como Usar a Tecnologia Para Resolver.

noreply@blogger.com (Apolineo) — Fri, 04 Jun 2010 20:54:00 +0000

A cerca de 8 anos acompanhamos a evolução da plataforma .NET da Microsoft, e em especial, a linguaguem C#. Isso claro, sem falar da UML, da Orientação a Objetos e Padrões de Projeto.

Tivemos oportunidades de colocar em prática muitos dos conceitos para que pudessemos sair de situações comerciais desfavoráveis. Por exemplo, imagine só, você se apresenta como referência na tecnologia, vende uma consultoria de estabilização de um pequeno sistema de B2B, e sem olhar o produto, estima em 1 mês, afinal, um sistema pequeno (22 telas de cadastro, 4 telas de média complexidade e 1 muito complexa) não deve ser tão dificil de estabilizar, certo?

Porém, conforme se passaram os dias, o que se viu foi que o sistema estava tão ruim que, certamente, 1 mês seria pouco. E logo se passaram quase 2 semanas.

Então, resolvemos analisar o sistema e a situação, e olhando o sistema funcionar vimos que todas as telas seguiam um padrão para as operações básicas (inclusão, alteração, pesquisa e exclusão), logo surgiu a luz, vamos implementar um conjunto de classes base que fizesse todo o CRUD, uma tela base que implementasse toda a lógica de utilização dessas classes, e então, alteramos a herança das telas e alteramos apenas para passar os dados específicos de cada item (lembrando que tudo isso foi em 2005 com .Net 1.1).

Levamos pouco mais de 1 dia para desenvolver e estabilizar as classes base, e mais outro dia, para alterar todas as telas. Pronto! O sistema estava estável e ganhamos 4 dias por conta da solução técnica.

E com um pouco de refatoração nesse conjunto de classes, pudemos aproveitá-las em outro projeto, o qual, em apenas 1 mês, fizemos o levantamento, a documentação, o desenvolvimento, a homologação e a implementação de um sistema de controle de ações de marketing com distribuidores (12 telas de cadastro, 2 telas de negócio e 3 relatórios).

A evolução desse trabalho é o lob Framework. Avalie o uso nos seus projetos e pare de investir tempo e dinheiro para criar e testar a infra-estrutura da aplicação.

Versão Trial em http://ww.apolineo.com.br/products.aspx

TI... o desafio nosso de cada dia

noreply@blogger.com (Apolineo) — Sat, 29 May 2010 00:51:00 +0000

É com muita satisfação que damos ínicio a um novo desafio em nossa empresa.

Através desse espaço esperamos compartilhar idéias e experiências, sejam boas ou ruins, dos projetos que estivermos envolvidos. Com isso, esperamos criar um ambiente de debate virtual que leve a debates presenciais e uma troca de experiências ricas para todos da comunidade de soluções baseadas em software.

Nos da Apolineo acreditamos que o sucesso está na utilização prática dos conceitos teóricos que circundam nossa área de estudo, porém, vemos no dia-a-dia, que muitas empresas partem para estratégias do rambo (aquela onde o melhor programador/desenvolvedor resolvedor de problemas luta contra tudo e contra todos para manter o software funcionando). Mas sabemos também que há outras empresas, exceções de mercado, que possuem uma política voltada ao ser humano, pois afinal, são eles que fazem a empresa, não são?

O pior disso tudo é que não conseguimos evoluir como profissionais e acabamos tendo que dedicar muito tempo do nosso lazer em estudos para nos mantermos competitivos no mercado.

Você sofre desses problemas?