Tags: , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 15/05/2011 09:22 | Comentários (5)

Olá pessoal!

Eu gostaria de compartilhar com vocês, nesse pequeno post, na diferença entre Requisito e Requerimento.

Requisito é a necessidade, ou seja, o problema a ser resolvido. Já Requerimento é o pedido formal de uma solução de um determinado problema, para um determinado Requisito. Simplificando, o artefato nasce como Requisito e depois da análise vira um Requerimento.

É comum que as empresas considerem apenas o termo Requisito para ambos os estados (ou momentos) do artefato. Porém, se algum dia você encontrar alguém se referindo a um Requerimento, considere que o Requisito já foi analisado e refinado, transformou-se em Requerimento, ou pedido, para posterior definição da solução do problema ou requisição. O Requerimento pode conter uma proposta de solução, ou não.

Pra quem não sabia, fica aí a dica.

Por hoje é só!

Até a próxima!

Tags: , | Categories: Padrões de Projeto Posted by Rafael on 12/05/2011 02:07 | Comentários (1)

Olá pessoal!

Hoje vamos falar um pouco sobre um padrão de criação bem simples, o padrão Prototype. Esse padrão tem como objetivo criar um "clone", ou seja, uma cópia, de um determinado objeto. Segue abaixo a definição do nosso livro base:

"Especificar os tipos de objetos a serem criados usando uma instância-protótipo e criar novos objetos pela cópia desse protótipo." [GAMMA, 2009].

Um dos diversos cenários que podemos aplicar o padrão Prototype é quando necessitamos guardar o estado de um objeto, em determinados pontos de execução de um processamento, por exemplo. Na maioria das vezes, é mais interessante criarmos "clones", ou cópias, de um objeto em determinado momento, do que criar a instância manualmente.

A estrutura do padrão Prototype é a seguinte:

Estrutura do Padrão Prototype

O padrão Prototype pode ser implementado em conjunto com os padrões AbstractFactory, Composite e Decorator. Estudaremos em breve sobre os dois últimos padrões citados.

No código de exemplo, criaremos uma classe abstrata chamada Ave que implementa a interface ICloneable, e uma classe concreta Calopsita que herda de Ave. O projeto completo pode ser baixado aqui: Prototype.zip (20,74 kb)

Segue o código implementado junto com a classe de teste:

Classe Ave.cs

Classe Calopsita.cs

Classe Teste

O resultado:

Resultado

Repare que o nome dos dois objetos é o mesmo, porém o código hash é diferente, ou seja, são objetos do mesmo tipo e com as mesmas características, porém, são objetos distintos.

Esse é o padrão Prototype, muito simples e fácil de entender e utilizar.

Até a próxima!

 

 

Referência Bibliográfica

GAMMA, Erich, Padrões de Projeto, Porto Alegre: Bookman, 2009.

Tags: , , | Categories: Padrões de Projeto Posted by Rafael on 07/05/2011 17:06 | Comentários (0)

Olá pessoal!

Hoje vamos falar um pouco sobre um padrão muito utilizado e, de igual modo, simples: o padrão Singleton.

Esse padrão tem como objetivo "garantir que uma classe tenha somente uma instância e fornecer um ponto de acesso global para a mesma". [GAMMA, 2000].

Em algumas situações precisamos garantir que apenas uma instância de uma determinada classe seja criada no contexto do sistema. São os casos de fazermos uso de propriedades específicas de configuração comuns à toda aplicação, utilização de um Proxy qualquer existente na sua empresa, que seja utilizado para integração dos sistemas, por exemplo.

Por se tratar de um padrão muito simples, vamos direto para a representação da sua estrutura, e logo em seguida para uma implementação de exemplo.

A estrutura do padrão Singleton é a seguinte:

Estrutura Singleton

Para que exista uma instância única na aplicação, precisamos criar um construtor privado na classe Singleton, uma variável estática, e implementarmos a lógica para criação da instância e o seu retorno. O código abaixo exemplifica isso:

Aqui está o projeto completo: Singleton.zip (20,92 kb)

Ao executar o projeto, se você inserir um breakpoint no método obterInstancia da classe ProxyConnectionDB e ir passo-a-passo, notará que ele cria a instância apenas na primeira execução (variável con1), pois a classe nunca foi utilizada. Porém, na segunda chamada (variável con2) o objeto já existe, e sua instância é retornada, sem criar uma nova instância.

O exemplo acima implementa o padrão Singleton pois tem um contrutor privado, e um método que cria e/ou retorna a instância da classe, que será acessada por um único ponto na aplicação.

Alguns padrões podem ser implementados usando Singleton. É o caso dos padrões Prototype, AbstractyFactory e Builder. Já conhecemos o padrão AbstractyFactory, e veremos os padrões Prototype e Builder em breve.

É isso!

Até a próxima!

 

 

Referência Bibliográfica

GAMMA, Erich, Padrões de Projeto, Porto Alegre: Bookman, 2009.

Tags: , , | Categories: Metodologia de Desenvolvimento Ágil Posted by Rafael on 06/05/2011 22:41 | Comentários (6)

Olá pessoal!

Nesse post comentarei sobre as principais vantagens e benefícios gerados a partir da adoção de processos baseados em metodologias ágeis, por qualquer empresa de Tecnologia da Informação.

"Metodologias ágeis têm sido apontadas como uma alternativa às abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas também como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situações em que os requisitos do sistema são estáveis e requisitos futuros são previsíveis. Entretanto, em projetos em que há muitas mudanças, em que os requisitos são passíveis de alterações, onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, não pode haver requisitos estáticos, necessitando então de metodologias ágeis. Além disso, o ambiente das organizações é dinâmico, não permitindo então que os requisitos sejam estáticos." [SOARES, 2011].

Um projeto nunca é igual a outro projeto, e quanto maior a empresa, maior a diversificação de projetos, em relação a tamanho, escopo, requisitos, custo e prazo. Ao longo dos últimos anos, tenho atuado em projetos dos ramos bancário, securitário e previdenciário, e, todos eles possuíam características diferentes. Uns demandaram uma formalização e um planejamento intensos, enquanto outros, nem tanto. Um dos grandes problemas enfrentados foi ter que passar por todo o processo de desenvolvimento padrão, preenchendo muitos artefatos, muitas das vezes, desnecessários para o projeto. 

Muitas empresas acreditam que ser ágil é o mesmo que ser informal. E isso não é verdade. Ser ágil, dentre outras características, é ser formal apenas nos momentos os quais a formalidade é necessária, dando fluência ao projeto.

Empresas do ramo bancário, por exemplo, têm como um dos principais requisitos para terem o direito de ofertar seus papéis na Bolsa de Valores de Nova York, a adesão à Lei Sarbanes-Oxley, ou SOX, que estabelece a confecção de diversos artefatos, definindo um processo para o desenvolvimento de produtos de software. O que algumas empresas não sabem, é que é possível atender aos requisitos da SOX dentro de um processo baseado numa metodologia ágil, gerando apenas os artefatos que são realmente necessários e importantes, para que o projeto não seja afetado pelo excesso de documento a serem criados, sem necessidade.

Uma grande preocupação das empresas é o número de horas extras geradas em cada projeto. Esse, sem sombra de dúvida, é um assunto que gera muito estresse para o projeto, e conseqüentemente a todos os stakeholders. O fato gerador desse desconforto no decorrer do projeto, na maioria das vezes, é a dificuldade de se planejar um projeto como um todo. O grau de assertividade de um planejamento de 120 dias certamente é menor do que um de 15 dias. Metodologias ágeis estabelecem entregas semanais, quinzenais ou mensais (às vezes bimestrais e até semestrais, mas a ocorrência é bem pequena em relação aos demais prazos), o que facilita muito o planejamento. 

"a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prática procura ratificar o foco nas pessoas e não em processos e planejamentos. Caso seja necessário, os planos devem ser alterados, ao invés de sobrecarregar as pessoas." [SOARES, 2011].

É fato que, se temos um problema menor, podemos atuar pontualmente e sermos mais assertivos em relação aos prazos e custos. Com isso, diminuímos a ocorrência de horas extras e sobrecarga de pessoal em fases críticas do projeto.

Outro grande problema presente enfrentado pelas empresas quanto à utilização de processos baseados em metodologias não ágeis de desenvolvimento de software é entrega única, apenas ao final do projeto. Em alguns casos, o pior acontece. O cliente vira pra você e diz: “Mas não foi isso que eu pedi!”. Esse cenário é, sem dúvida, um dos mais críticos para um projeto, pois tempo, dinheiro, expectativa, confiabilidade “foram para o ralo”. 

"Entregas freqüentes visa à construção de um software simples, e conforme os requisitos surgem, há a atualização do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo e melhora as avaliações do cliente, aumentando a probabilidade do software final estar de acordo com os requisitos do cliente." [SOARES, 2011].

Se adotarmos a técnica de entregas freqüentes, o risco de esse cenário acontecer tende a zero, pois a cada entrega, recebemos um feedback do cliente sobre o entregado, facilitando assim, ajustarmos as pendências para convergir às expectativas do cliente.

"Para prevenir a degradação da qualidade devido a entregas muito curtas, dá-se alta ênfase a testes do produto ao longo do ciclo de vida. Métodos ágeis requerem testes de integração ao longo do processo de desenvolvimento. Automação dos testes é importante para que as "builds" diárias passem por testes de regressão." [ABRANTES, 2011].

Outro benefício que a adoção de entregas menores e mais freqüentes traz para o projeto é a sobrecarga de testes dos requisitos classificados como críticos, ou de alta complexidade. Durante o planejamento do projeto, os requisitos são classificados segundo sua complexidade e criticidade. É uma boa prática de desenvolvimento baseado em metodologias ágeis a implementação dos requisitos de maior complexidade, pois, a cada nova entrega, todos os requisitos são retestados, o que diminui exponencialmente o risco de não conformidade com a especificação dos mesmos.

A cooperação e interação entre cliente e equipe de desenvolvimento do projeto também é um ponto forte nos processos de desenvolvimento baseados em metodologias ágeis.

"Interação aberta e com proximidade entre os vários stakeholders (especialmente entre cliente e desenvolvedores); o cliente deve tomar parte ativa no processo de desenvolvimento e prover opinião de forma regular e freqüente." [ABRANTES, 2011].

Quando o cliente faz parte do projeto, interagindo com a equipe, dando opinião e agindo realmente como parte integrante do projeto, alguns problemas enfrentados hoje por algumas empresas "caem por terra". Alguns usuários muitas das vezes mal explicam o que querem, aprovam as especificações dos requisitos às vezes sem se preocupar muito em ler todo o documento, pensando que o que não está escrito, está implícito, largando a equipe do projeto durante todo o desenvolvimento, retornando apenas no período de homologação. Essa atitude é muito freqüente em empresas que adotam apenas a forma não ágil de desenvolvimento. A metodologia ágil prega que o cliente precisa estar junto, participar, interagir, registrar feedbacks, ou seja, fazer parte do projeto.

"Todo dia, é feita uma reunião de 15 minutos onde o time expõe à gerência o que será feito no próximo dia, e nestas reuniões os gerentes podem levantar os fatores de impedimento, e o progresso geral do desenvolvimento." [SANTOS, 2011].

Outra característica muito importante dos métodos ágeis é a realização de rápidas reuniões diárias, onde são expostos de maneira pontual quais são as tarefas a serem executadas no próximo dia, o que ajuda a guiar a atenção e foco da equipe para o que realmente é importante naquele momento, ou seja, o sprint atual, fazendo o que é importante e necessário agora, e postergando o que pode ser postergado, sem causar impacto para o projeto. Algumas empresas realizam reuniões com o mesmo objetivo, porém, para tratar questões de tarefas de semanas ou meses, o que aumenta muito o escopo da reunião, prejudicando a tomada de decisões, ocupando grande parte do tempo e com foco menos pontual, o que dificulta a resolução dos problemas.

"Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas." [BECK, 2011].

A única certeza que temos quando começamos um projeto é a de que os requisitos serão alterados. Muitas equipes têm uma resistência enorme às alterações de requisitos ao final do projeto, principalmente pelo custo e esforço enormes necessários para a realização da mudança. Em métodos ágeis esse custo e esforço tende a ser menor, o que facilita muito a vida de todos os envolvidos no projeto. 

"Lei do foco, ou da concentração: menos é mais" e "Lei do progresso: podemos criar mais com menos" [KOCH, 2009].

Uma das técnicas, ou teorias, aplicadas em métodos ágeis (largamente aplicado na administração de empresas e auto-ajuda) é o Princípio de Paretto, também conhecimento como Princípio 80/20, que prega basicamente que podemos atingir 80% dos resultados esperados focando em apenas 20% das tarefas. Essa explanação parece muito simplista, mas quando aplicada à realidade de uma empresa, no que concerne o desenvolvimento de aplicativos com métodos ágeis, faz todo sentido. Ao invés de gastarmos uma grande parte do tempo fazendo planejamentos enormes, criando artefatos gigantescos sem necessidade, vamos direto ao foco, separando as atividades por risco e complexidade, o que facilita a compreensão de cada parte do problema, mantendo o foco no que é realmente importante, gerando os resultados esperados com muito menos esforço e desperdício de tempo e dinheiro.

Esses são os principais pontos que uma empresa deve levar em consideração para a adoção de um processo de desenvolvimento de software baseado em métodos ágeis. Sem dúvida, é interessante para qualquer tipo de empresa que faz uso da tecnologia da informação, para condução do seu negócio, fazer uso de métodos ágeis para o desenvolvimento de seus softwares.

Mais informações em http://agilemanifesto.org/

Até a próxima!

 

 

Referências Bibliográficas

SOARES, Michel Dos Santos Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software, disponível em http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf em 04/05/2011.

ABRANTES, José Fortuna e Guilherme Horta Travassos Caracterização de Métodos Ágeis de Desenvolvimento de Software, disponível em http://reuse.cos.ufrj.br/wdra2007/images/artigos/30188.pdf em 04/05/2011.

SANTOS, Rogério Guaraci Dos e Giulian Dalton Luz Métodos Ágeis, disponível em http://www.ime.usp.br/~gdaltonl/ageis/ageis_6pp.pdf em 04/05/2011.

BECK, Kent Manifesto Ágil, disponível em http://manifestoagil.com.br/principios.html em 04/05/2011.

KOCH, Richard, O Estilo 80/20, Rio de Janeiro: Sextante, 2009.