Manifesto das Regras de Negócio

Os princípios da independência da regra
por Business Rules Group


Artigo 1. Requisitos como elementos principais, nunca secundários
1.1. As regras são um cidadão de primeira classe no mundo dos requisitos.
1.2. As regras são essenciais para os modelos de negócio e para os modelos de tecnologia, sendo uma parte separada e específica dos mesmos.

 Artigo 2. Independentes dos processos, não contidas neles
2.1. As regras são restrições explícitas de comportamento e/ou proporcionam suporte ao comportamento.
2.2. As regras não são processos nem procedimentos, pelo que não devem estar contidas em nenhum deles.
2.3. As regras aplicam-se transversalmente a processos e procedimentos. Deve existir um corpo coeso de regras, que se aplique de forma consistente a todas as áreas relevantes de atividade de negócio.

 Artigo 3. Conhecimento explícito, não um sub-produto
3.1. As regras constroem-se sobre fatos, e os fatos sobre conceitos que são expressos por termos.
3.2. Os termos expressam conceitos de negócio; os fatos constituem asserções sobre estes conceitos; as regras restringem e suportam estes fatos.
3.3. As regras devem ser explícitas. Nunca se deve assumir nenhuma regra sobre nenhum conceito ou nenhum fato.
3.4. As regras são os fundamentos que definem o que o negócio sabe de si mesmo – isto é, são o conhecimento base do negócio.
3.5. As regras necessitam de ser alimentadas, protegidas e geridas.

 Artigo 4. Declarativas, não procedimentais
4.1. As regras devem ser expressas de forma declarativa em frases de linguagem natural, perceptíveis pela audiência conhecedora do negócio em causa.
4.2. Se algo não pode ser expresso, então não é uma regra.
4.3. Um conjunto de enunciados só é declarativo se não contém uma sequência implícita.
4.4. Todo o enunciado de regras que precise de outros elementos para além de termos ou fatos, requere assunções sobre uma implementação de sistema.
4.5. Uma regra é distinta de qualquer medida definida para o seu cumprimento. A regra e a forma do seu cumprimento são questões distintas.
4.6. As regras devem definir-se independentemente de quem é responsável pelo
seu cumprimento, e de onde, quando e como se fazem cumprir.
4.7. As exceções às regras são expressas por outras regras.

 Artigo 5. Expressões bem formadas,não Ad Hoc
5.1. As regras de negócio devem ser expressas de forma a que os especialistas do negócio possam validar a sua correção.
5.2. As regras de negócio devem ser expressas de forma a permitir verificar reciprocamente a sua consistência.
5.3. As lógicas formais, como a lógica de predicados, são fundamentais para a expressão formal, bem formada, das regras em termos de negócio, assim como para as tecnologias que implementam estas regras.

Artigo 6. Arquitetura baseada em regras, não uma implementação indireta
6.1. Um sistema baseado em regras de negócio é construído intencionalmente para permitir a mudança constante das regras de negócio. A plataforma sobre a qual o sistema é executado deve suportar esta evolução contínua.
6.2. Executar diretamente as regras – por exemplo através de motores de regras – é uma estratégia de implementação melhor que transcrevê-las de forma procedimental.
6.3. Um sistema de regras de negócio deve ser sempre capaz de explicar as razões pelas quais chega a uma conclusão ou toma uma ação.
6.4. As regras baseiam-se em valores de verdade. A forma como se determina ou mantém o valor de verdade de uma regra é mantida oculta dos usuários.
6.5. A relação entre eventos e regras é geralmente de muitos-para-muitos.

Artigo 7. Processos orientados às regras, não programação baseada em exceções
7.1. As regras definem a fronteira entre uma atividade de negócio aceitável e não aceitável.
7.2. As regras requerem frequentemente um tratamento especial ou seletivo das violações detectadas. Qualquer atividade derivada da violação de uma regra constitui uma atividade como qualquer outra.
7.3. Para assegurar a consistência e a reutilização máxima, o tratamento de atividades de negócio não aceitáveis deve separar-se do tratamento das atividades de negócio aceitáveis.

Artigo 8. Ao serviço do negócio, não da tecnologia
8.1. As regras tratam de práticas e orientações do negócio; portanto, as regras são motivadas pelas metas e os objetivos de negócio, e são moldadas por diversas influências.
8.2. As regras implicam sempre um custo para o negócio.
8.3. O custo da aplicação das regras deve ser valorizado e balanceado, tendo em consideração os riscos assumidos pelo negócio, e as oportunidades perdidas no caso de não as aplicar.
8.4. “Mais regras” não é necessariamente melhor. Normalmente é preferível ter poucas mas “boas regras”.
8.5. Um sistema eficaz pode basear-se num número pequeno de regras. Posteriormente,podem adicionar-se regras mais específicas de forma que ao longo do tempo o sistema se torne mais inteligente.

 Artigo 9. “De, por e para” as pessoas do negócio, e não “de, por e para” as pessoas de TI
9.1. As regras devem provir das pessoas conhecedoras do negócio.
9.2. Os especialistas do negócio devem dispor de ferramentas que os auxiliem a formular, validar e gerir regras.
9.3. Os especialistas de negócio devem dispor de ferramentas que os ajudem a verificar consistência recíproca entre regras de negócio.

 Artigo 10. Gerir lógica de negócio, não plataformas de Hardware/Software
10.1. As regras de negócio são um ativo vital do negócio.
10.2. A longo prazo, as regras são mais importantes para o negócio que as plataformas de Hardware/Software.
10.3. As regras de negócio devem ser organizadas e armazenadas de forma que possam ser facilmente redistribuídas para novas plataformas de Hardware/Software.
10.4. As regras, e a capacidade de as alterar de forma eficaz, são fatores chave para melhorar a adaptabilidade do negócio.

Fonte: http://www.rildosan.com/2013/06/manifesto-das-regras-de-negocio.html apud Copyright, 2003. Business Rules Group. Versão 2.0, Novembro 1, 2003. Editado por Ronald G. Ross. www.BusinessRulesGroup.org

Ferramentas (para testes de software)

Todas as ferramentas listadas abaixo são Open Source. Esta lista foi criada a partir de uma pesquisa realizada em grupos de discussão de testes, onde os participantes listaram estas ferramentas como as mais utilizadas nas empresas em que trabalham.

Testes Funcionais em Aplicações WEB

• Selenium - http://seleniumhq.org
• Watir - http://wtr.rubyforge.org
• BadBoy - http://www.badboy.com.au
• actiWATE - http://www.actiwate.com
• Canoo WEBTest - http://WEBtest.canoo.com
• Apodora - http://www.apodora.org

Testes de Desempenho

• JMeter - http://jakarta.apache.org/jmeter

Gestão de Casos de Teste

• TestLink - http://www.teamst.org
• TestMaster - http://testmaster.sourceforge.net

Gestão de Defeitos

• Bugzilla - http://www.bugzilla.org
• Mantis - http://www.mantisbt.org
• Redmine - http://www.redmine.org
• Jira - http://www.atlassian.com/software/jira

Processo de Testes

O que é Teste de Software?

A atividade de teste de software é o processo de executar um sistema com a intenção de descobrir um erro.

O que é um teste bem sucedido?

É aquele que  revela um erro ainda não descoberto.

Cenários comuns no contexto de testes de softwares

• Falta de planejamento do tempo e custo;
• Preparação e execução do teste são feitas superficialmente;
• O teste é a última etapa do processo de desenvolvimento;
• Testes são tratados como causador de aumento dos custos e prazos dos projetos;
• Testes são executados pela equipe de desenvolvimento;

Esses cenários são visto com frequência nas empresas de software. Temos que levar em consideração que a falta de planejamento e preparação, a execução tardia e pelos próprios desenvolvedores influenciam negativamente na qualidade dos produtos. Os testes devem ser efetuados de maneira planejada e por profissionais de teste.

Testar software envolve:

• Processos
• Equipe de Teste
• Versões de software(s
• Releases
• Ferramentas

A parti do momento que o planejamento do processo de desenvolvimento do software é iniciado devemos também iniciar o planejamento dos testes. Todas as etapas do processo de testes devem ser executadas em paralelo com o processo de desenvolvimento.

Níveis de teste de software

O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software.

Os principais níveis de teste de software são:

Teste de Unidade: também conhecido como testes unitários. Tem por objetivo explorar a menor unidade do projeto, procurando provocar falhas ocasionadas por defeitos de lógica e de implementação em cada módulo, separadamente. O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código.

Teste de Integração: visa provocar falhas associadas às interfaces entre os módulos quando esses são integrados para construir a estrutura do software que foi estabelecida na fase de projeto.

Teste de Sistema: avalia o software em busca de falhas por meio da utilização do mesmo, como se fosse um usuário final. Dessa maneira, os testes são executados nos mesmos ambientes, com as mesmas condições e com os mesmos dados de entrada que um usuário utilizaria no seu dia-a-dia de manipulação do software. Verifica se o produto satisfaz seus requisitos.

Teste de Aceitação: são realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.

Teste de Regressão: Teste de regressão não corresponde a um nível de teste, mas é uma estratégia importante para redução de “efeitos colaterais”. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Pode ser aplicado em qualquer nível de teste.

Modelo V

1. Inicialmente é planejado o teste de aceitação a partir do documento de requisitos;

2. Após isso é planejado o teste de sistema a partir do projeto de alto nível do software;

3. Em seguida ocorre o planejamento dos testes de integração a partir o projeto detalhado;

4. E por fim, o planejamento dos testes a partir da codificação.

Este modelo introduz a criação de testes e cenários de teste durante o ciclo de desenvolvimento do software, ao contrário de outros que só fazem testes no fim do ciclo. Este modelo disponibiliza diferentes estados de teste.

 Vantagens do modelo V:

• A fase de teste começa no início do ciclo.
• A segunda fase de testes é extremamente reduzida.
• Os “test plans” detalhados em cada fase do ciclo ajudam compreender melhor o qual a origem do problema.
• O modelo V é um standard internacional para o desenvolvimento de sistemas IT, sendo superior ao modelo cascata e ao modelo espiral no endereçamento de grandes projetos IT.

Desvantagens:

• Continua a não ser suficientemente flexível;
• É necessário maior feedback entre todas as fases do ciclo.

Dream Theater - Constant Motion

Iron Maiden - Face in the Sand

Iron Maiden - Man Of The Edge

Clean Code Cheat Sheet (click to enlarge)

Let's Listen: Donkey Kong Country - Aquatic Ambience (Extended)

Donkey Kong Country - Soundtrack (SPC)

Aquatic Ambiance (Donkey Kong Country) on piano

Vantagens e Desvantagens do Controle de Versão Distribuído

Controle de versão distribuído (Distributed Version Control Systems – DVCS) é a mais nova geração de sistemas de controle de versão de software. Apesar de o conceito existir já há algum tempo, recentemente as ferramentas se tornaram maduras o suficiente para chamar a atenção de diversos projetos open source, que migraram ou expandiram seu suporte do Subversion (centralizado) para o Mercurial, Git e Bazaar (distribuídos) por exemplo.

Mas o que tem de errado com o controle de versão centralizado? Nada. Ele usa uma estrutura que atende muito bem a grande parte das equipes de desenvolvimento de software. Baseia-se na arquitetura cliente-servidor, com um repositório central (servidor) e cópias de trabalho para os desenvolvedores (clientes).

Para equipes de desenvolvimento com acesso ao repositório pela rede local, essa arquitetura funciona bem. A velocidade da rede não é problemática, o tempo de resposta do processamento é aceitável e todos os desenvolvedores da equipe têm permissão de leitura e escrita no repositório.

Não foi para resolver exatamente esse tipo de necessidade que o controle de versão distribuído foi criado. Imagine uma situação diferente:

• Equipe com centenas de desenvolvedores. Significa que mais processamento vai ser exigido do servidor central, piorando o tempo de resposta;
• Equipe espalhada em diferentes filiais da empresa. Acesso remoto ao repositório com limitações de conexão e de permissão de escrita;

A arquitetura cliente-servidor não funciona tão bem para essas situações. Soluções alternativas como aumentar a capacidade de processamento do servidor ou replicar os repositórios nem sempre são viáveis ou fáceis de serem implementadas.

Para essas situações, a arquitetura peer-to-peer, na qual o controle de versão distribuído se baseia, é muito mais adequada.

Benefícios do Controle de Versão Distribuído

As vantagens estão relacionadas à distribuição do processamento, redundância/replicação de repositórios e as novas possibilidades de colaboração entre desenvolvedores.

Do ponto de vista do desenvolvedor

• Rapidez. As operações são processadas localmente. Não é necessário passar pela rede e contatar o servidor central para fazer um commit, log ou diff por exemplo.
• Autonomia. A conexão com a rede só é necessária para trocar revisões com outros repositórios. Fora isso, trabalha-se desconectado e em qualquer lugar, como num cliente por exemplo.
• Ramos privados. Além de um repositório próprio, o trabalho local é feito em um ramo privado que não interfere, nem sofre interferência dos demais, mesmo nas operações de sincronização entre repositórios. O momento de combinar um ramo com outro é uma decisão do desenvolvedor e não obrigatório antes de cada commit, como acontece no centralizado.
• Facilidade de Mesclagem. Só a facilidade de criação de ramos não seria suficiente se não fosse o rastreamento automático usado pelos DVCS, que torna o processo de mesclagem muito mais simples e indolor. Observação: No Subversion, o rastreamento automático de merges começou a partir da versão 1.5

Do ponto de vista da gerência/coordenação

Parte das decisões gerenciais envolve manter livre o caminho da equipe para que possam trabalhar da melhor maneira possível. Outras decisões importantes são sobre redução de custos. Nestes dois casos específicos, o modelo distribuído oferece as seguintes vantagens:

• Confiabilidade. No sistema centralizado, uma pane no servidor interrompe todo o desenvolvimento. Já no sistema distribuído, além de a equipe poder continuar seu trabalho (observação: veja a seção “controle de mudança ainda é centralizado” mais abaixo), os repositórios dos desenvolvedores funcionam como cópias de backup de todo o projeto.
• Redução de custos com servidor. A carga de processamento fica distribuída nas próprias máquinas dos desenvolvedores. O repositório “central”, quando existe, tem o papel do repositório “oficial” e não como processador central das requisições.

Em que situações o controle de versão distribuído não vai tão bem?

Nem tudo são flores com o modelo distribuído de controle de versão.

Maior complexidade

No centralizado, os desenvolvedores trabalham no mesmo ramo, seja esse ramo o principal ou um ramo de manutenção.

Essa forma de trabalho é mais simples de se entender. Mesmo que limitadamente, uma pessoa com pouco conhecimento de controle de versão consegue trabalhar com o resto da equipe.

O modelo distribuído é mais complicado. A arquitetura peer-to-peer, ramos privados e as mesclagens aparentemente desordenadas podem tornar o grafo da evolução do projeto confuso à primeira vista.

Ao contrário do centralizado, não adianta só commit e update para funcionar “no tranco”. Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferência, também de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos. Só assim, o grafo acima deixa de ser apenas um emaranhado e passa a representar muito claramente o fluxo do trabalho.

Travamento de arquivos binários precisa ser centralizado

Diferentemente dos arquivos de texto, arquivos binários possuem um formato interno que não é baseado em linhas de texto e, por isso, não podem ser mesclados automaticamente pelo controle de versão ou manualmente pelo desenvolvedor.

Sendo assim, a edição concorrente de arquivos binários é problemática. Duas pessoas editando ao mesmo tempo uma figura, por exemplo, não conseguirão mesclar as modificações depois e o trabalho de uma delas precisará ser refeito.

Com arquivos binários, a melhor solução é usar o travamento, isto é, sinalizar que o arquivo está travado para edição e que ninguém mais deve editá-lo enquanto isso.

O modelo puramente distribuído não é adequado para lidar com travamento justamente por não possuir um servidor central que possa controlar as travas de todos.

Controle de mudança ainda é centralizado

As ferramentas de controle de mudança (e.g. Trac, Redmine, Mantis, Bugzilla) ainda não acompanharam as de controle de versão na arquitetura peer-to-peer. Isto significa que mesmo usando um DVCS, ainda haverá uma ferramenta centralizada para controle de mudança.

O ideal seria que o controle de versão e o controle de mudança  fossem integrados e distribuídos, tal como é no Fossil. Essa ferramenta parece ser interessante, mas ainda é muito incipiente.

Resumo das Características do Controle de Versão Distribuído

Ponto de Vista	Vantagens	Desvantagens
Desenvolvedor	Rapidez Autonomia Ramos Privados Facilidade de Mesclagem	Necessidade de maior conhecimento da ferramenta e do processo
Coordenação/Gerência	Redução de custos com servidor e infraestrutura externa de rede Confiabilidade Aumento da produtividade	Necessidade de maior capacitação de desenvolvedores Importante ter um processo definido O controle de mudança ainda precisa ser centralizado

Considerações Finais

Controle de versão distribuído oferece muitas vantagens interessantes. Mesmo projetos que não se encaixam diretamente no perfil podem se beneficiar. Entretanto, por ser um pouco mais complexo, o modelo distribuído requer mais preparo da equipe e também do processo, o que não chega a ser realmente um impedimento uma vez que um processo formalizado e equipes capacitadas são fundamentais para produção de software de qualidade.

Em um próximo artigo, vou analisar alguns pontos que ajudarão a decidir a viabilidade ou não de se mudar do centralizado para o controle de versão distribuído.

Referências e Leitura Complementar

1. Conceitos Básicos de Controle de Versão Centralizado e Distribuído
2. Capítulo 1 do manual o Mercurial
3. Distributed Version Control Systems – Why and How
4. Distributed Revision Control

Fonte: http://pronus.eng.br/blog/http:/pronus.eng.br/blog/qual-a-melhor-ferramenta-de-controle-de-versao-subversion-git-ou-mercurial

Requirements Engineering

Especificação e Análise de Requisitos de Software

“A parte individual mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita errado. Nenhuma outra parte é mais difícil de consertar depois” [Fred Brooks]

“Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objetivos e requisitos para os quais foi construído. De forma geral, a Engenharia de Requisitos de Software é o processo de identificar todos os envolvidos, descobrir seus objetivos e necessidades e documentá-los de forma apropriada para análise, comunicação e posterior implementação [4]” [Ricardo Falbo, notas de Aula, Engenharia de Software, 2005]

Love, Reign O'er Me- Pearl Jam

Good songs can be found everywhere and anytime. Please do yourself a favor. Search the original.

My Favorite Player of Street Fighter II