Arquivo de outubro 2009
Testes de Software
27/10/09
Recentemente estive envolvido em um projeto onde qualidade e tempo andavam em lados opostos, qualidade a equipe tem e muita, porém nos faltava tempo. “O projeto deve ser entregue dentro de 15 dias” e após muita luta e esforço de todos, conseguimos o prazo de 30 dias, dependendo do tamanho do projeto isso poderia ser um ótimo prazo, mas não para esse.
Um portal para fins educativos, com conceitos chaves como COMUNICAÇÃO, GESTÃO E CONTEÚDO.
Infelizmente não posso falar o nome da empresa. Você agora deve esta se perguntando certo mais o que isso tem haver com TESTES DE SOFTWARE, pois bem a equipe conseguiu terminar o projeto dentro do prazo, porém na apresentação para a direção da empresa, vários repito vários BUGS foram surgindo na apresentação.
O que ficou claro para todos foi a equipe esqueceu uma fase importante e talvez junto com a implementação a fase mais dispendiosa, mais cara como alguns acadêmicos definem, a fase de TESTES. Não que nenhum dos programadores não tenha testado o que faziam, sim eles faziam isso, porém não realizavam testes mais profundos no momento em que as funcionalidades eram adicionadas, isso gerou a equipe RETRABALHO, pois além de parar todo o desenvolvimento para realizar os testes, “Já que éramos uma equipe pequena que fazia uso de metodologia ágil”, nos tínhamos uma certeza “falhamos”, não pelo que foi feito e sim pelo o que não foi feito.
Mas Rafael por que contar toda essa historinha para falar de testes? Por que não ir direto ao ponto, onde você falaria das questões como testes servem para detectar defeitos e não acertos. Por que não falar das estatísticas que mostram que empresa que investem no estudos e aplicações de testes como algo primordial para o processo de desenvolvimento de software obtém ótimos resultados do ponto de vista de qualidade, satisfação do cliente, menos retrabalho.
Não falei, pois tudo isso já é falado aos quatro cantos do mundo. O que queria mostrar é que até mesmo uma equipe de alto nível pode falhar feio, se subestimar a engenharia de software, pois para muitos, o que Summerville, Pressman entre outros pregam não são aplicáveis ao mundo real de desenvolvimento de software.
Não é ter que aplicar tudo que esta na teoria para a prática e sim os conceitos ou boas práticas junto com suas necessidades é claro. No próximo POST “amanhã”, eu irei falar sobre uma outra forma de evitar problemas com bugs INSPEÇÃO DE SOFTWARE.
OO parte III – Atributos
08/10/09
Atributos, que também podem ser chamados de propriedades, são responsáveis por representar as características de uma classe, permitindo assim diferenciar um objeto do outro, por exemplo, o atributo cor da classe Carro irá identificar a cor de cada Objeto do tipo carro. Assim o carro1 poderá ter a cor vermelha e o carro2 poderá ser azul.
Atributos são representados na segunda divisão da classe, geralmente possuem dois campos, um destinado ao nome do atributo e outro destinado ao tipo de dado armazenado pelo atributo, por exemplo, integer, float, character ou boolean, sendo que esse ultimo não é obrigatório.
Assim, todo objeto possui atributo e esse atributos são responsáveis por dar características ao objeto, como por exemplo na classe Cliente do exemplo abaixo, da representação de uma classe com atributos.
OO parte II – Classe
07/10/09
A classe é uma estrutura estática e será útil para descrever os objetos, seus atributos (propriedades) e métodos (funcionalidades). A classe é um modelo ou template para criação destes objetos. Podem ser classes, qualquer entidade do negócio da sua aplicação (Usuário, Cliente, Filme).
No momento que modelamos um Cliente, por exemplo, são suas propriedades (nome, idade, sexo). E temos como métodos, funcionalidades desempenhadas pela classe. No caso de Cliente, poderiam ser métodos (Comprar(), Alugar(), Vender()).
Uma classe pode ser representada por um retângulo, dividido em 3 partes. A primeira armazena o nome da classe, a segunda lista os atributos da classe e a última lista os métodos que a classe possui. Podemos encontrar classes que possuam apenas uma dessas partes ou características.
A figura acima mostra o exemplo de uma classe, note que nesse caso só possui uma divisão, já que não é obrigatório representar a classe expandida.
*Nos Próximos posts estaremos falando mais das outras divisões.
Introdução a orientação a objetos
06/10/09
O que é OO?
Orientação a objetos (OO) é um paradigma de desenvolvimento de softwares. Que em vez de construir um sistema baseado num conjunto de procedimentos e variáveis, que nem sempre são agrupados de acordo com o contexto, na orientação a objetos utiliza-se uma ótica mais próxima do mundo real, onde se lida com objetos, onde muitas vezes são estruturas já conhecidas no dia-a-dia e as quais são mais bem-compreendidas.
Vantagens
- maior facilidade para reutilização de código e por conseqüência do projeto.
- possibilidade do desenvolvedor trabalhar em um nível mais elevado de abstração.
- utilização de um único padrão conceitual durante todo o processo de criação de software.
- maior adequação à arquitetura cliente/servidor.
- maior facilidade de comunicação com os usuários e com outros profissionais de informática.
- ciclo de vida mais longo para os sistemas.
- desenvolvimento acelerado de sistemas.
- possibilidade de se construir sistemas muito mais complexos, pela incorporação de funções prontas.
- menor custo para desenvolvimento e manutenção de sistemas.
Desvantagens
- complexidade no aprendizado para desenvolvedores de linguagens estruturadas.
- maior esforço na modelagem de um sistema OO do que estruturado (porém menor esforço de – codificação, sendo uma vantagen).
- funcionalidades limitadas por interface, quando estas estão incompletas (problemas na modelagem).
- dependência de funcionalidades já implementadas em superclasses no caso da herança, implementações espalhadas em classes diferentes.
* No proximo post estaremos falando sobre classes, não percam.
