Teste durante ciclo de vida do software

Desenvolvimento, Qualidade de Software, ,

AntesMyers_DepoisMyers

O processo de testes deve contar com uma metodologia favorável ao processo de desenvolvimento, dispor de colaboradores qualificados, ambiente e ferramentas adequadas. “A metodologia de testes deve ser o documento básico para organizar a atividade de testar aplicações no contexto da empresa.” (RIOS; MOREIRA, 2006, p. 8).

O processo de teste deve iniciar paralelamente ao processo de desenvolvimento. Podendo verificar os documentos produzidos no inicio do projeto de desenvolvimento. Ainda neste âmbito, Myers (1979, apud Bastos et al. 2007, p. 19) estabeleceu a Regra 10 de Myers, na qual defende que quanto mais tarde for encontrado um erro, tende a ser mais caro a sua correção.

Untitled-1

Referências

RIOS, Emerson; MOREIRA, Trayahú. Teste de software. 2. ed. Rio da Janeiro: Alta
Books, 2006. 232 p.
MYERS, G. J. The art of software testing. 2. ed. Hoboken: Wiley, 2004.
BASTOS, Aderson et al. Base de conhecimento em teste de software. 2. ed. São
Paulo: Martins, 2007. 264 p.

Extreme Programming

Desenvolvimento, Dicas, , , ,

xp1

Extreme Programming (XP), idealizado por Kent Beck, é um processo de desenvolvimento de software iterativo e incremental que se encaixa na categoria de metodologias ágeis. Ele busca entregar o máximo de valor para o cliente com o uso de boas práticas. A sua aplicação é recomendada para projetos que possuem requisitos voláteis e pouco claros e para aqueles projetos desenvolvimento de maneira incremental [Teles 2004, p. 21].

A metodologia XP é baseada em 4 valores, como descreve [Teles 2004, p. 22]:

  • Feedback: Durante o andamento do projeto, o cliente aprende novas regras ou requisitos que são realimentados para a equipe de desenvolvimento. Isto permite conduzir o processo para aquilo que irá gerar mais valor.
  • Comunicação: Uma comunicação transparente e efetiva entre o cliente e o time de desenvolvimento permite uma maior eficiência na transmissão de informações.
  • Simplicidade: O desenvolvimento de software deve ser guiado apenas pelas soluções que são suficientes para atender aos desejos do cliente.
  • Coragem: Tanto o cliente quanto a equipe de desenvolvimento devem ser corajosos para aplicar as práticas e valores do XP, acreditando que isso irá trazer benefícios para o seu produto.

Para apoiar estes valores, o XP sugere a aplicação das seguintes práticas [Teles 2004, p. 23-27]:

  • Cliente presente: o cliente deve coordenar o andamento do projeto baseado nos feedbacks recebidos durante o processo de desenvolvimento.
  • Jogo de planejamento: o cliente avalia as funcionalidades a serem desenvolvidas e as prioriza para as próximas iterações ou releases.
  • Stand Up Meeting: reunião diária realizada pela equipe de desenvolvimento para avaliar o andamento da iteração.
  • Programação em Par: prática de desenvolvimento que consiste em dois programadores implementando em um mesmo computador. Isto permite que o desenvolvimento seja mais simples e eficaz, além de contribuir para a revisão de código enquanto é construído.
  • Desenvolvimento guiado pelos testes: os desenvolvedores escrevem testes para suas funcionalidades antes de codificá-las.
  • Refactoring: A equipe de desenvolvimento deve, regularmente, manter a sua base de código flexível para facilitar o refactoring (modificação do código sem alterar o seu comportamento).
  • Código coletivo: todos os desenvolvedores possuem acesso ao código do sistema, sem restrição de acesso.
  • Código padronizado: a equipe deve estabelecer um padrão de codificação e formatação de código.
  • Design simples: o desenvolvimento deve ser voltado para as soluções mais simples e enxutas para atender aos requisitos.
  • Metáfora: significa a utilização de termos de negócio usados pelo cliente, a fim de facilitar a transmissão de ideias complexas de forma simples.
  • Ritmo sustentável: o XP recomenda que a equipe de desenvolvimento trabalha oito horas por dia e evitem fazer horas-extras, visto que isso evita que a equipe perca criatividade e motivação no trabalho.
  • Integração contínua: prática que define que a equipe deve, diversas vezes ao dia, integrar e testar o código produzido com a base de código já existente. Isto permite garantir que o sistema esteja sempre funcionando de forma harmoniosa.
  • Releases curtos: o XP permite gerar um fluxo contínuo de valor para o cliente através de entregas frequentes (a cada iteração).

Estes valores e práticas fazem do XP uma metodologia simples de ser aplicada e ao mesmo tempo pode trazer grandes resultados. Porém, nas palavras de [Teles 2004, p.219], ”a maior dificuldade na venda do XP é exatamente a barreira cultural que precisa ser vencida. XP é diferente e o que é diferente costuma causar medo e ansiedade”. É necessário um grande grau de maturidade (tanto por parte do cliente quanto por parte do time de desenvolvimento) para implantar este processo e se beneficiar de seu uso.

 

Referência

Teles, V. M. (2004). Extreme Programming. Novatec.

Scrum

Desenvolvimento, Dicas, , , , ,

scrum-glossary-agile-terms

O Scrum é um modelo de processo de desenvolvimento ágil de software fundamentado nas teorias empíricas de controle do processo, ou empirismo. Sua abordagem é iterativa e incremental possibilitando assim aperfeiçoar a previsibilidade e o controle de riscos [Schwaber and Sutherland 2013, p. 4].

Segundo [Cisneiro et al. 2013, p. 4] o nome Scrum é derivado de uma jogada de rúgbi, onde todo o mesmo time avança como apenas uma unidade, trabalhando com os mesmos jogadores e em conjunto, passando sempre a bola pra um e para outro.

Conforme [Schwaber and Sutherland 2013, p. 4], três pilares sustentam qualquer implementação de controle de processos empíricos:

  • Transparência: Garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados.
  • Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas.
  • Adaptação: Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

Segundo [Schwaber and Sutherland 2013, p. 5] os papéis existentes no Scrum são:

  • ScrumMaster: é o responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras, ajuda o Time Scrum e a organização a adotarem o Scrum.
  • Product Owner: á a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Backlog do Produto e garante que ele está visível para todos.
  • Time (equipe de desenvolvimento): Transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Times também são interdisciplinares: seus membros devem possuir todo o conhecimento necessário para criar um incremento no produto.

[Neto 2013] diz que o objetivo de se ter eventos no Scrum é proporcionar um maior controle sobre o processo adquirindo uma rotina de trabalho e aumentar a transparência ao decorrer do desenvolvimento. Os eventos Scrum são time boxed, ou seja, possuem uma duração máxima definida. Não se pode garantir o sucesso de um projeto com o uso do Scrum deixando de incluir qualquer um dos seus eventos que são:

  • Sprint: Uma Sprint consiste em um espaço de tempo de no máximo quatro semanas.Onde é desenvolvido por o Development Team um produto potencialmente utilizável. O tempo de duração de uma Sprint pode variar entre duas a quatro semanas, essa é uma decisão compartilhada por o Scrum Team. Cada Sprint deve ter um objetivo a ser alcançado pelo Development Team, resultando em um incremento do produto final.
  • Sprint Planning Meeting: O Sprint Planning Meeting é a reunião de planejamento que ocorre antes do início de uma Sprint como resultado de um trabalho colaborativo do Scrum Team.
  • Daily Scrum Meeting: é uma reunião diária geralmente de 15 minutos. O seu objetivo principal é fazer o Development Team refletir a respeito das seguintes questões: “O que foi completado desde a última reunião?”, “O que será feito até a próxima reunião” e ”quais os obstáculos que estão no caminho?”. Essa reunião assegura que o Development Team está seguindo a direção correta em relação ao objetivo da sprint.(SCHWABER, 2011, pg 10).
  • Sprint Review: acontece ao final de cada Sprint e tem como objetivo avaliar o que foi produzido pelo Development Team. É uma reunião com duração de 4 horas para Sprints de um mês.
  • Sprint Retrospective: esta é uma reunião de duração de três horas para uma Sprint de um mês. Tem como objetivo avaliar o desempenho do Development Team, criando melhorias a esse respeito para a próxima Sprint.

[Cisneiro et al. 2013, pg 8] cita que artefatos Scrum são as ferramentas básicas para se trabalhar com este modelo de desenvolvimento. Estes artefatos servem como guias e indicadores durante o processo. São divididos em três:

  • Product Backlog: o Proprietário do Produto prepara uma lista de funcionalidades desenvolvida em conjunto com o cliente, que é organizada por prioridade de entrega. Essa lista chama-se Product Backlog.
  • Sprint Backlog: assim que a equipe de Scrum escolher e definir a lista de requisitos e a prioridade de seus itens do Product Backlog, cada um desses itens agora será dividido em partes menores para o Sprint Backlog. Ou seja, uma lista especificando as necessidades para implementar uma funcionalidade do sistema.
  • Burndown Chart: é um gráfico que mostra a quantidade de trabalho cumulativo restante de um Sprint, dia por dia. Com isto, podemos visualizar facilmente se um trabalho está tendo progresso, completando as tarefas, enquanto vemos que as colunas do gráfico vão caindo em sua altura.

Estes conceitos e artefatos propostos pela metodologia de desenvolvimento Scrum se utilizadas da forma correta em projetos onde a agilidade possa ser empregada irá proporcionar a empresa a possibilidade de produzir softwares que satisfaçam os clientes, com uma boa qualidade e agilidade.

Referências

Cisneiro, H., Jacoba, M. S., and Pereira, S. M. T. (2013). Modelo de desenvolvimento ágil scrum. Disponível em: http://www.devin.com.br/modelo-scrum/. Acesso em: 06 Mai. 2013.

Neto, C. (2013). Conhecendo o scrum. Disponível em: http://www.devmedia.com.br/conhecendo-o-scrum/25744. Acesso em: 29 Abr. 2013.

Schwaber, K. and Sutherland, J. (2013). Guia do scrum, 2011. Disponível em: http: //www.scrum.org/Scrum-Guides. Acesso em 06 Mai. 2013.

Boletos maliciosos de renovação de domínios

Dicas, , ,

Em razão de continuadas tentativas de iludir a boa fé dos usuários do Registro brasileiro, alertamos para que prestem atenção aos boletos recebidos que não sejam provenientes de seu provedor de hospedagem habitual.

Boletos do Registro.br devem ser obrigatoriamente emitidos através do nosso website. O Registro.br não envia mais boletos por via postal em nenhuma circunstância; correspondências relativas à cobrança pelo Registro.br tem apenas um endereço web de nosso próprio site (https://registro.br/…) que permite a emissão do boleto.

Boletos emitidos no site do Registro.br, referentes ao pagamento do registro e manutenção de domínio sob o “.br”, possuem as seguintes informações:

CEDENTE NIC.br – CNPJ 05.506.560/0001-36
BANCO 237-2 – Bradesco
AGÊNCIA/CÓDIGO CEDENTE 2370-1 / 0029998-7

Observem também na parte superior do boleto a existência do logotipo do Registro.br e os dados do NIC.br, conforme imagem abaixo:

Dados do Boleto

O valor do boleto emitido pelo NIC.br depende do período de manutenção escolhido para seu domínio, podendo variar de 1 a 10 anos. Para saber mais clique aqui.

Em caso de dúvida, antes de realizar o pagamento, contate a nossa Central de Atendimento.

Fonte: Registro BR
Texto retirado do site: http://registro.br

Custom Post Types no WordPress

Wordpress

wordpress-logo-hoz-rgb

Hoje o WordPress não é visto mais como apenas uma ferramenta de administração de blogs mas sim como um poderoso CMS, ou seja, um grande gerenciador de conteúdo.

Como acostumamos com o WordPress para blogs presenciamos apenas alguns tipos de postagens que se fazem presentes como criação de páginas e posts.

Para darmos mais flexibilidade e podermos explorar outros tipos de conteúdos no WordPress podemos criar Custom Post Types (Tipos de posts customizados) para o distribuirmos as nossas postagens de forma como bem entendermos, como por exemplo, criar tipos de conteúdo para produtos, notícias, fotos, entre outros distintamente.

Temos duas opções que podem ser utilizadas para a criação dos tipos de post: a solução de forma manual ou a solução que envolve menos código fonte e se faz uso de um plugin. Bom, facilitando a vida de todos inclusive a minha vamos pelo lado mais interessante e mais fácil, que é a utilização do plugin More Types  que fará esse processo de criação de novos conteúdos.

Ao instalar o plugin pelo WordPress ele se localizará em Configurações -> More Types. Entrando nas configurações do plugin agora é fácil, acionamos o botão “Add new Post Type” e partimos para o cadastro do post type. Obrigatóriamente cadastramos o nome do nosso tipo de conteúdo em “Post type name singular” esse vai ser um nome que identificará esse tipo de conteúdo de preferência sem acentos, espaços e utilizando somente letras minúsculas, como por exemplo: produtos.

Depois disso temos várias opções para a personalização da nossa seção conforme as suas necessidades. Antes do botão “Save” temos uma aba “Advanced settings” com mais opções e configurações do post type criado. Após a configuração é só salvar o seu conteúdo. Após salvar atualize sua página, que a sua seção estará disponível na coluna da esquerda de seu gerenciador.

custom_post_types_exemple

Usando o Custom post type no seu template

Depois de configurado o novo tipo de post e tendo cadastrado alguns, precisamos fazer com que ele apareça em seu template no lugar desejado.

Então no lugar desejado do seu template precisamos chamar o nosso tipo de conteúdo através das tags utilizadas pelo o WordPress. No nosso caso o código para a inserção do tipo de conteúdo “produtos” ficaria assim:

 

$args = array( 'post_type' => 'produtos', 'posts_per_page' => 10 );

$loop = new WP_Query( $args );

   while ( $loop->have_posts() ) : $loop->the_post();

     the_title();

     the_content();

   endwhile;

 

Pronto inserido este loop do WordPress com os seus devidos parâmetros configurados, teremos o nosso tipo de conteúdo “produtos” aparecendo no seu template no lugar onde você preferir e da forma como preferir.

Espero ter ajudado, em breve retorno com outro post sobre como fazer Fields(Campos) personalizados para complementar o nosso Custom Post Type(Tipo de conteúdo personalizado).

Um pouco sobre Multitenancy

Java

No último semestre do curso tivemos as apresentações dos trabalhos finais. Na ocasião, comentei um pouco sobre multitenancy e seus impactos em uma aplicação java já existente, propondo um framework que facilite a adaptação e programação nessa situação. O Hibernate 4 já possui algo desenvolvido nesse sentido, dando suporte a multitenancy com bases de dados separadas, mas parece que vários avanços estão por vir, podendo até ter suporte a multitenancy com a base de dados compartilhada.

Em anexo a este post, está uma versão em PDF do Trabalho de Conclusão de Curso, onde pode-se encontrar mais informações a respeito do assunto.

Como instalar Epoptes no Linux Educacional 4.0

Dicas, Linux Educacional, Tecnologia Educacional,

Epoptes é um software open source para gerenciamento de laboratórios de informática. Ele permite o monitoramento de computadores, execução de comandos, envio de mensagens, bloqueio de tela, desligar, reiniciar e muitos outros recursos.

O Epoptes deve ser instalado no servidor e nos clientes que desejamos monitorar. Os passos seguintes devem ser feitos tanto no Servidor como nos Clientes.

Primeiramente execute o comando abaixo para instalar o patch

sudo apt-get install patch

Para o Linux Educacional devemos baixar uma versão otimizada do Epoptes.

Quem nunca trabalhou com PPAs no LE4 precisa baixar este patch antes de prosseguir:
http://redmine.c3sl.ufpr.br/attachments/download/106/distro.py-fix-linux-educacional.patch

Agora entre na pasta onde foi baixado o arquivo, extraia o arquivo, e depois execute o seguinte comando também dentro do diretório onde se encontra o arquivo:

sudo patch -p0 < distro.py-fix-linux-educacional.patch

Vamos então adicionar o PPA no Linux Educacional 4

sudo apt-add-repository ppa:oiteam/proinfo-83.2008

(substitua por 71.2010, dependendo do seu pregão)

Esses passos devem ser realizados tanto no Servidor como nos Clientes.

Agora somente no Servidor execute os comandos para instalar o Epoptes

sudo apt-get update && sudo apt-get install epoptes

Após instalar os pacotes, adicione o usuário professor ao grupo epoptes do seu servidor, executando o seguinte comando:

sudo gpasswd -a professor epoptes

Os passos abaixo devem ser feitos somente nos Clientes

sudo apt-get update && sudo apt-get install epoptes-client

Agora,  vamos usar o kate para editar o arquivo de configuração.

sudo kate /etc/default/epoptes-client

Na linha 7, retire o # da frente da palavra SERVER e substitua o valor depois do = pelo IP do servidor. Exemplo:

SERVER=192.168.0.114

Para descobrir o IP do Servidor digite o comando:

ifconfig

E, na saída, veja o valor do campo inet end da placa de rede desejada. No meu caso, é 192.168.0.114.

Após modificar o arquivo de configuração e salvá-lo vamos obter o certificado OpenSSL do servidor.

sudo epoptes-client -c 192.168.0.114

Substitua o valor 192.168.0.114, pelo IP do seu Servidor.

Para que o Epoptes inicie automaticamente quando ligarmos os Clientes vamos adicionar um script na pasta AutoStart do LE.

Crie um arquivo com o nome epoptes.sh com o conteúdo abaixo, no lugar do IP 192.168.0.114 você deve colocar o IP do seu Servidor encontrado anteriormente:

#!/bin/sh
epoptes-client 192.168.0.114

Agora pelo terminal entre na pasta onde foi baixado o arquivo e execute o comando abaixo para copiar o arquivo para a pasta Autostart de cada usuário, faça isso para cada usuário que você tiver no computador. Substitua aluno1 do comando abaixo, pelo nome de cada usuário, aluno2, aluno3, por exemplo.

sudo cp epoptes.sh /home/aluno1/.kde/Autostart/

Vamos dar permissão de execução ao arquivo copiado para a pasta Autostart, faça isso também para cada usuário, substituindo aluno1, por aluno2 etc.

sudo chmod 765 /home/aluno1/.kde/Autostart/epoptes.sh

Pronto, é só reiniciar os computadores e usar esse excelente programa.

 

 

 

 

 

 

Como excluir (definitivamente) perfil do Facebook

Dicas

Nesse post será ensinado como excluir o perfil do Facebook, na maioria dos post na internet apenas ensinam a desativar o perfil, sendo que, digitando o usuário e senha, a conta volta como estava antes. O procedimento deste post é irreversível, você excluirá definitivamente o seu Facebook.

Para ficar mais simples eu já peguei o endereço da página para excluir o perfil, então com o Facebook aberto copie e cole no seu navegador o link abaixo, esse link já vai te direcionar à página para excluir o perfil.

https://www.facebook.com/help/delete_account

A página que vai aparecer é a seguinte:

Depois disso você receberá um email informando que a conta será excluída no prazo de 14 dias.