Software systems

Software systems are abstract and intangible. They are not constrained by the
properties of materials, governed by physical laws, or by manufacturing processes.
This simplifies software engineering, as there are no natural limits to the potential of
software. However, because of the lack of physical constraints, software systems can
quickly become extremely complex, difficult to understand, and expensive to change.

Gestão da qualidade total e o Clico PDCA

Gestão da qualidade (TQM) consiste numa estratégia de administração orientada a criar consciência de qualidade em todos os processos organizacionais. O TQM (Total Quality Management) tem sido amplamente utilizado em indústria, educação, governo e serviços. Chama-se total porque o seu objetivo é a implicação não só da empresa inteira mais também a organização estendida: fornecedores, distribuidores e demais parceiros de negócios. O TQM é composta de estágios tais como: planejamento, Organização controle, liderança. Tanto qualidade quanto manutenção são qualificadas de total porque cada empregado que participa é diretamente responsável pela realização dos objetivos da empresa.

Atualmente a gestão da qualidade está sendo uma das maiores preocupações das empresas, sejam elas voltadas para a qualidade de produtos ou de serviços. A conscienciatização para a qualidade e o reconhecimento de sua importância, tornou a certificação de sistemas de gestão da qualidade indispensável para as micro e pequenas empresas de todo o mundo.

Uma organização que se propõe a implementar uma política de gestão voltada para a "qualidade" tem consciência de que a sua trajetória deve ser reavaliada. As mesmas precisam pôr em prática atividades que visam estabelecer e manter um ambiente no qual as pessoas, trabalhando em equipe, consigam um desempenho eficaz na busca das metas e missões da organização.

CICLO PDCA

É uma das formas que a empresa tem para começar a gestão de qualidade é se preocupar com seus processos, e para isso pode se utilidade de uma ferramenta chamada de CLICO PDCA, essa ferramente é de grande utilidade na busca da melhoria continua.

O ciclo PDCA, ciclo de Shewhart ou ciclo de Deming, foi introduzido no Japão após a guerra, idealizado por Shewhart e divulgado por Deming, quem efetivamente o aplicou. O ciclo de Deming tem por princípio tornar mais claros e ágeis os processos envolvidos na execução da gestão, como por exemplo na gestão da qualidade, dividindo-a em quatro principais passos. O PDCA é aplicado principalmente nas normas de sistemas de gestão e deve ser utilizado (pelo menos na teoria) em qualquer empresa de forma a garantir o sucesso nos negócios, independentemente da área ou departamento (vendas, compras, engenharia, etc...).

O ciclo começa pelo planejamento, em seguida a ação ou conjunto de ações planejadas são executadas, checa-se se o que foi feito estava de acordo com o planejado, constantemente e repetidamente (ciclicamente), e toma-se uma ação para eliminar ou ao menos mitigar defeitos no produto ou na execução.

Os passos são os seguintes:

Plan (planejamento) : estabelecer missão, visão, objetivos (metas), procedimentos e processos (metodologias) necessários para o atingimentos dos resultados.
Do (execução) : realizar, executar as atividades.
Check (verificação) : monitorar e avaliar periodicamenteos resultados, avaliar processos e resultados, confrontando-os com o planejado, objetivos, especificações e estado desejado, consolidando as informações, eventualmente confeccionando relatórios.
Act (ação) : Agir de acordo com o avaliado e de acordo com os relatórios, eventualmente determinar e confeccionar novos planos de ação, de forma a melhorar a qualidade, eficiência e eficácia, aprimorando a execução e corrigindo eventuais falhas. 

Veja a tabela de etapas do PDCA:

Há dois tipos de metas no clico PDCA: 

• Metas para manter

O PDCA utilizado para atingir metas padrão, ou para manter os resultados num certo nível desejado, pode então ser chamado de SDCA (S de standard).

• Metas para melhorar

De modo a atingir novas metas ou novos resultados, a "maneira de trabalhar" deve ser modificada, ou seja, melhorada.

Melhoria contínua 

A melhoria contínua ocorre quanto mais “rodado” for o Ciclo PDCA.
Observe na figura abaixo, como a melhoria ocorre em função do tempo no processo anterior e após a aplicação do PDCA.

A melhoria contínua otimiza a execução dos processos, possibilita a redução de custos e o aumento da produtividade.

A aplicação do Ciclo PDCA a todas as fases do projeto leva ao aperfeiçoamento e ajustamento do caminho que o empreendimento deve seguir, mesmo os processos considerados satisfatórios são passíveis de melhorias. A introdução de melhorias gradativas e contínuas aos processos só tendem a agregar maior valor aos resultados do projeto e a assegurar maior satisfação dos clientes.

Human beings and Computers

"Computers are incredibly fast,
accurate and stupid. Human
beings are incredibly slow,
inaccurate and brilliant.
Together they are powerful
beyond imagination."

Ontologia x Taxonomia: Diferenças

As taxonomias trabalham no sentido de organizar a informação e/ou conhecimento, em relações hierárquicas entre os termos. Já as ontologias, buscam estabelecer relações semânticas entre conceitos, em forma de redes conceituais, próximas da estrutura que trabalha a mente humana.

Ontologia

 Taxonomia

Software Engineering and their Relationship to Computer Science

The Systems Approach

Não se discute que em nossa época há uma grande confusão a respeito da maneira  como nossa sociedade é dirigida. Provavelmente em nenhum momento da história do homem houve tanta discussão sobre os acertos e os erros dos autores do modo de conduzir os assuntos, quer sejam políticos do Brasil ou USA, quer sejam administradores em grandes organizações ou pessoas que dirigem instituições educacionais. Em todos estes casos o ciddadão sente  que tem perfeito direito de dar sua opinião sobre o modo como os administradores administram.

Não somente o cidadão passou a ter muito mais voz ativa, mas em muitos momentos começou também a suspeitar  que os homens que tomam as decisões de maior importância, que afetam nossas vidas, não sabem o que estão fazendo. Não sabem o que estão fazendo porque não tem uma base adequada para julgar os efeitos de suas decisões.

Para muitas pessoas deve parecer que vivemos numa época tomada de decisões imbecis. Quase tudo que o autor de uma decisão tem que fazer é aprender um aspecto da situação e levá-lo adiante tanto quanto possível, argumentando contra os seus inimigos na base de que estes não conseguem perceber a verdadeira situação.

Use sua inteligência emocional e tenha ótimos resultados

Somos entusiastas da tecnologia e, a cada momento, percebemos que os métodos tradicionais de relacionamento estão sendo colocados à parte, seja pela quantidade de informação que assimilamos diariamente ou pela conveniência dos sistemas que acabam pensando e agindo por nós. Mas, como sabemos, é impossível transmitir a emoção em relacionamentos automatizados, um simples e-mail pode produzir dezenas de interpretações e sentimentos.
Você tem idéia de como é perigoso não estar em contato com suas emoções? Até pouco tempo atrás o sucesso de uma pessoa era avaliado pelo raciocínio lógico e habilidades matemáticas e espaciais (QI). Mas o psicólogo Daniel Goleman, PhD, retoma uma nova discussão sobre o assunto. Ele traz o conceito da inteligência emocional como maior responsável pelo sucesso ou insucesso das pessoas. A maioria das situações de trabalho é envolvida por relacionamentos entre as pessoas. Desta forma, pessoas com qualidades de relacionamento humano, como afabilidade, compreensão, gentileza têm mais chances de obter o sucesso, e conseqüentemente, maior assertividade.
A Inteligência Emocional está relacionada a algumas habilidades sociais, tais como: motivar a si mesmo e persistir mediante frustrações; controlar impulsos, canalizando emoções para situações apropriadas; praticar gratificação prorrogada; motivar pessoas, ajudando-as a liberarem seus melhores talentos e conseguir seu engajamento em objetivos de interesses comuns.

Benefícios da Inteligência Emocional:
a) Desenvolver bons relacionamentos com os “stakeholders” que estão apoiando o projeto;
b) Antecipar e evitar esgotamentos;
c) Lidar com membros difíceis da equipe e gerenciar conflitos;
d) Incrementar as informações emocionais para tomar decisões melhores;
e) Comunicar-se de modo mais eficaz;
f) Criar um ambiente de trabalho positivo e um alto moral na equipe;
g) Criar uma visualização de cenário para objetivos compartilhados no projeto, com o intuito de atrair, inspirar e motivar a equipe, entre outros…
O psicólogo Howard Gardner da Universidade de Harward, nos Estados Unidos, propõe “uma visão pluralista da mente” ampliando o conceito de inteligência única para o de um feixe de capacidades. Para ele, inteligência é a capacidade de resolver problemas ou elaborar produtos valorizados em um ambiente cultural ou comunitário. Assim, ele propõe uma nova visão da inteligência, dividindo-a em sete diferentes competências que se interpenetram, pois sempre envolvemos mais de uma habilidade na solução de problemas.

Embora existam predominâncias, as inteligências se integram:
• Inteligência Verbal ou Lingüística: habilidade para lidar criativamente com as palavras.
• Inteligência Lógico-Matemática: capacidade para solucionar problemas envolvendo números e demais elementos matemáticos; habilidades para raciocínio dedutivo.
• Inteligência Cinestésica Corporal: capacidade de usar o próprio corpo de maneiras diferentes e hábeis.
• Inteligência Espacial: noção de espaço e direção.
• Inteligência Musical: capacidade de organizar sons de maneira criativa.
• Inteligência Interpessoal: habilidade de compreender os outros; a maneira de como aceitar e conviver com o outro.
• Inteligência Intrapessoal: capacidade de relacionamento consigo mesmo, autoconhecimento.
• Habilidade de administrar seus sentimentos e emoções a favor de seus projetos. É a inteligência da auto-estima.
Segundo Gardner, todos nascem com o potencial das várias inteligências. A partir das relações com o ambiente, aspectos culturais, algumas são mais desenvolvidas ao passo que deixamos de aprimorar outras.
Nos anos 90, Daniel Goleman, também psicólogo da Universidade de Harward, afirma que ninguém tem menos que nove inteligências. Além das sete citadas por Gardner, Goleman acrescenta mais duas:
• Inteligência Pictográfica: habilidade que a pessoa tem de transmitir uma mensagem pelo desenho que faz.
• Inteligência Naturalista: capacidade de uma pessoa em sentir-se um componente natural.
Sem dúvida, foram essas afirmações que se transformaram em manchete e fizeram a IE ser tão notada.

Até hoje, lamentavelmente, existem muitas controvérsias entre os pesquisadores sobre o que são exatamente as emoções. Uma possível definição de emoção é: “Um estado mental que surge espontaneamente e não por meio de esforço consciente.
Normalmente, é acompanhado de alterações fisiológicas. É, portanto, “um sentimento como são as emoções de alegria, de tristeza, da reverência, do ódio e do amor.” David E. Carlson, no seu livro Counseling and Self-Esteem (algo como Recomendações e Autoestima), usa seis palavras – sad, angry, scared, happy, excited e tender (triste, irado, amedrontado, feliz, animado e carinhoso), que ele resumiu no acrônimo SASHET – para poder entender uma ampla gama de emoções. (ver Figura 1)

Certamente, seria conveniente se a Inteligência Emocional fosse fácil de medir, assim como a altura ou o peso de uma pessoa. Infelizmente isso não acontece!
A boa notícia sobre Inteligência Emocional é que, não importa como você está agora, a maioria dos especialistas concordam que os conhecimentos podem ser aperfeiçoados e melhorados ao longo de toda sua vida.

Uma pequena avaliação segue abaixo:
1. Você acredita que deveria ficar mais animado do que fica normalmente com certo evento?
2. Você não chora em circunstâncias nas quais acredita que outras pessoas chorariam?
3. Você se orgulha de nunca ficar irritado?
4. Você fica surpreendido quando descobre que suas expectativas sobre outras pessoas não coincidem com o que de fato acontece?
5. Alguém já lhe disse que você é grosso, insensível ou negligente?
6. Você acha que os problemas que as pessoas têm são, em grande parte, culpa delas?
7. Você acha difícil trabalhar com pessoas da sua equipe cujo nível educacional é diferente do seu?
8. Você fica chateado ou incapaz de se concentrar quando um familiar ou um integrante da sua equipe está com um problema sério?
9. Você se irrita com seu cônjuge, seus filhos ou integrantes de sua equipe de projeto por comentários inofensivos, porém humorísticos sobre seu desempenho?
10. Seus amigos mais próximos ou seu cônjuge comentam que você não sabe lidar bem com suas emoções?
11. Você freqüentemente faz piadas ou usa do sarcasmo com os seus colaboradores ou seus amigos?
12. Você costuma “sair batendo o pé” das reuniões, batendo portas ou enviando e-mails raivosos, tudo porque as suas colocações não foram aceitas?
13. Seus relacionamentos com sua equipe de projeto, seus colaboradores, gerentes e patrocinadores são superficiais e limitados à tarefa do momento?
14. Seus conflitos com determinados indivíduos são constantes?
15. Você se sente uma vítima dos outros ou acha que diz “sim” quando, na verdade, quer dizer “não”?
16. As pessoas costumam sair da equipe de projeto quando ficam sabendo que você é o líder?
17. Para você, comunicar-se com os outros é algo muito difícil?
18. Fica surpreso quando a sua equipe não entende os objetivos do projeto que está sendo proposto?
19. Em seus projetos, você vivencia conflitos que parecem nunca se resolverem?
20. Você quer ser melhor no que se refere a estabelecer um carisma ou sua presença como líder?
Para se auto-avaliar, conte o seu número total de respostas “não”. Quanto menor for este número, maiores e mais significativas são as oportunidades para melhorar a sua inteligência emocional, porém se o número estiver entre 17 e 20, você é quase um gênio emocional que faz parte de uma minoria de profissionais que sabe lidar com muita eficiência com as suas emoções e as dos outros.
Agora, imaginem a complexidade de um sistema com essa capacidade de interpretação!

Importância das Emoções

Sobrevivência: Nossas emoções foram desenvolvidas naturalmente através de milhões de anos de evolução. Como resultado, nossas emoções possuem o potencial de nos servir como um sofisticado e delicado sistema interno de orientação. Nossas emoções nos alertam quando as necessidades humanas naturais não são encontradas. Por exemplo, quando nos sentimos sós, nossa necessidade é encontrar outras pessoas.Quando nos sentimos receosos, nossa necessidade é por segurança. Quando nos sentimos rejeitados, nossa necessidade é por aceitação.

Tomadas de Decisão: Nossas emoções são uma fonte valiosa da informação. Nossas emoções nos ajudam a tomar decisões. Os estudos mostram que quando as conexões emocionais de uma pessoa estão danificadas no cérebro, ela não pode tomar nem mesmo as decisões simples. Por que? Porque não sentirá nada sobre suas escolhas.

Ajuste de limites: Quando nos sentimos incomodados com o comportamento de uma pessoa, nossas emoções nos alertam. Se nós aprendermos a confiar em nossas emoções e sensações isto nos ajudará a ajustar nossos limites que são necessários para proteger nossa saúde física e mental.

Comunicação: Nossas emoções ajudam-nos a comunicar com os outros. Nossas expressões faciais, por exemplo, podem demonstrar uma grande quantidade de emoções. Com o olhar, podemos sinalizar que precisamos de ajuda. Se formos também verbalmente hábeis, juntamente com nossas expressões teremos uma possibilidade maior de melhor expressar nossas emoções. Também é necessário que nós sejamos eficazes para escutar e entender os problemas dos outros.

União: Nossas emoções são talvez a maior fonte potencial capaz de unir todos os membros da espécie humana. Claramente, as diferenças religiosas, cultural e política não permitem isto, apesar dar emoções serem "universais".

Inteligência Emocional

Inteligência Verbal ou Linguística: habilidade para lidar criativamente com as palavras.
Inteligência Lógico-Matemática: capacidade para solucionar problemas envolvendo números e demais elementos matemáticos; habilidades para raciocínio dedutivo.
Inteligência Cinestésica Corporal: capacidade de usar o próprio corpo de maneiras diferentes e hábeis.
Inteligência Espacial: noção de espaço e direção.
Inteligência Musical: capacidade de organizar sons de maneira criativa.
Inteligência Interpessoal: habilidade de compreender os outros; a maneira de como aceitar e conviver com o outro.
Inteligência Intrapessoal: capacidade de relacionamento consigo mesmo, autoconhecimento. Habilidade de administrar seus sentimentos e emoções a favor de seus projetos. É a inteligência da auto-estima.
Inteligência Pictográfica: habilidade que a pessoa tem de transmitir uma mensagem pelo desenho que faz.
Inteligência Naturalista: capacidade de uma pessoa em sentir-se um componente natural.

O explosivo Voltaire

Yes - Leave it

Trevor Rabin-Something to hold on to.

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