Tem muita gente que gosta da informação completa e iniciaria este relato em 3500 aC com a invenção do Ábaco, não deixaria de comentar as invenções de 1600 (Réguas de Cálculos, Calculadora de Páscal) e algumas outras que não serão comentadas a fundo aqui, porque não pretendo comentar as invenções precursoras ou mesmo a chamada geração 0.
A primeira geração de computadores, propriamente dita, existiu dos anos 30 até o final da década de 50. Estas máquinas construídas com relés e válvulas eletrônicas chegavam a fantástica velocidade de cálculos em milésimos de segundos. Tinham dispositivos de entrada e saída primitivos e cartões perfurados eram o melhor meio encontrado na época para fazer o armazenamento de informações.
De curiosidade, o ENIAC que foi concluído em 1946 pesava 30 toneladas e ocupava 180 metros quadrados, havia sido projetado para fazer complexos cálculos estratégicos para o exército americano, mas ficou pronto apenas depois da guerra. Ele não tinha sistema operacional e funcionava de forma muito semelhante a uma calculadora dos tempos de hoje.
Depois, com a invenção dos transistores em 1948 muitos novos projetos foram levados adiante na área da computação. Além dos transistores (que também fizeram os computadores serem menos suscetíveis a temperatura) também surgiu as memórias de anéis ferromagnéticos (fita magnética) que se tornou a forma de armazenamento comum da época.
Com esta tecnologia, surge a IBM na década de 60, que conseguiu lançar um computador incrivelmente barato perto do ENIAC chamado de IBM 7090 que custava "apenas" 3 milhões de dólares que é um dos maiores exemplos da chamada segunda geração. E a própria IBM lançou ainda no início dos anos 60 o IBM 7040 que era inferior em processamento, mas com um custo ainda menor que o IBM 7090.
Dos transistores, passamos as pastilhas de silício de circuitos integrados (chips), que conseguiam substituir cerca de mil transistores com uma única pastilha através da técnica de SSI (Small Scale Integration). Com isso os computadores diminuiram de tamanho e preço ainda mais. E pouco depois, em 1964, surgiu o IBM 360 que é um clássico da terceira geração de computadores. Eram chamados de Minicomputadores, também conhecidos como MainFrames, que forneciam processamento aos chamados "terminais burros". Pontos de acesso que apenas serviam de interface para o computador de verdade graças a tecnologias de multi-processamento. Ele era capaz de realizar 2 milhões de adições ou 500 mil multiplicações por segundo.
Durante a década de 70 foi que começaram duas grandes tecnologias para os dias de hoje. A primeira foi uma rede criada para ligar 4 minicomputadores, chamada de ARPANET, que era a semente da Internet que conhecemos hoje.
A segunda tecnologia foi a técnica LSI (Large Scale Integration), que conseguiu combinar até 65 mil componentes em uma única pastilha de silício. Que culminou com a Intel criando o primeiro microprocessador, Intel 4004 em 1971. E começaram a surgir os microcomputadores e computadores pessoais em 1975 com o Altair 8800. Depois em 76 uma empresa de garagem, chefiada por Sthephen Wozniak e Steve Jobs criou o Apple I que serviu de base para o Apple II, apenas um ano mais tarde, que foi o primeiro grande sucesso comercial de computadores pessoais. E ainda nos anos 70 a VLSI (Very Large Scale Integration) foi desenvolvida conseguindo colocar milhões de componentes em uma única pastilha de silício.
Em 1981 a IBM também entrou no mercado dos microcomputadores com o PC que em pouco tempo se tornou um padrão de mercado. E por volta de 1983 a ARPANET evoluiu para uma rede militar chamada MILNET nos EUA e MINET na Europa utilizando-se da mesma tecnologia. Além disso, eles conectaram as duas redes à ARPANET (que passou a ser utilizada por universidades e empreiteiras americanas) e ligaram as redes americanas e européias com links limitados via satélite. Em pouco tempo se tinha mais de 100 mil usuários.
A década de 90 não foi marcada por uma evolução do hardware do computador, mesmo tendo os computadores avançado incrivelmente em velocidade neste período. 1990 marcou o lançamento do WWW, que havia sido proposto um ano antes. Ou seja, o lançamento da internet como conhecemos hoje. Em 92 já havia mais de 1 milhão de servidores na internet. Em 1995 é que é feito o lançamento do Internet Explorer do Windows e provedores de BBS (com conexão discada) passam a oferecer a conexão com a internet realmente. Em 97 se alcança a marca de 19 milhões de servidores no mundo todo. A banda larga também começou a surgir no fim desta década.
Mas foi só no início da década seguinte que nos EUA a banda larga começou a crescer mais rápido que a conexão discada, em 2001. Redes de distribuição Peer to Peer que começaram com o Napster no final da década anterior cresceram bastante, mesmo com seu precursor tendo falhado, tornando a distribuição pirata de softwares, filmes e músicas bastante comum. E em fevereiro de 2005 o site YouTube foi criado, mostrando que a capacidade da internet para videos já começava a ser aceitável e promissora. Hoje em dia, é possível fazermos video chamadas de telefones celulares, GPS portáteis e muitas outras tecnologias.
sábado, 8 de agosto de 2009
quarta-feira, 5 de agosto de 2009
Técnicas e Estratégias de Validação de Software
O principal para uma boa estratégia de validação é minimizar os problemas o mais cedo possível. Mas nem sempre isso é possível, então
O que um bom plano deveria conter:
1-) Testes Unitários (desenvolvedor);
De preferência automáticos, para garantir que serão bons testes (testes unitários manuais tendem a fazer o "caminho feliz").
Os testes podem ser estruturais (caixa branca), funcionais (caixa preta) ou de regressão (testes que verificam que o resultado final não mudou), mas para ajudar com o desenvolvimento dos testes unitários existem algumas técnicas de cobertura de código:
- Partição em classes de equivalência (Equivalence class partitioning) - usar amostragem de cada possível valor que os parâmetros de entrada podem assumir
- Análise de valores limite (Boundary Value Analysis) - nestes testes deve-se conferir os valores limites do software, onde há alterações de decisão
- Transição de estados (State Transition Testing) - utilizado para testar as chamadas máquinas de estados e conferir que as transições estão acontecendo corretamente;
- Tabela de decisão (Decision Table) - tabela com as variáveis como condições e quais ações tomar baseando-se em seus resultados, para verificar que estas sequências funcionam;
- Testes Empareados (Pairwise Testing) - para cada par de parâmetros de entrada de um sistema, testa-se todas as combinações destes parâmetros;
2-) Testes de Sistemas (desenvolvedor);
Verificações com o sistema funcionando ou testes de partes integradas e não mais de funções individuais. Pode-se fazer uma integração incremental ou total em cada etapa de testes.
Já para os testes de integração, é bom contar com algumas técnicas um pouco mais amplas:
Integração Não-Incremental que usa a abordagem Big-Bang - já integra todo o software e testa ele todo integrado;
Integração Incremental onde o programa é construído e testado em pequenos segmentos e cada vez se agrega uma parte maior do software;
Integração Top-Down - integra e testa de cima para baixo;
Integração Botton-Up - integra e testa de baixo para cima;
3-) Validação (testador independente);
Execução de roteiros de validação mesmo. E como chegamos na hora de validar o sistema como um todo, é necessário conhecermos um pouco mais do que é necessário se considerar para garantir a qualidade do software. Segundo a ISO/IEC 9126 temos as seguintes características gerais para levar em consideração:
- Funcionalidade (satisfaz as necessidades?);
- Confiabilidade (é imune a falhas e estável?);
- Usabilidade (é fácil de usar?);
- Eficiência (é rápido e eficiente?);
- Manutenibilidade (é fácil de alterar e de manter?);
- Portabilidade (é fácil de ser utilizado em outro ambiente?);
4-) Testes de Aceitação (usuário final/gerente de produto);
Deixar o produto nas mãos deste usuário para validar as funcionalidades novas, pode encontrar outros problemas, mas não há roteiro envolvido.
Já escrevi sobre este assunto algumas vezes e podem encontrar outras matérias sobre testes no meu blog.
O que um bom plano deveria conter:
1-) Testes Unitários (desenvolvedor);
De preferência automáticos, para garantir que serão bons testes (testes unitários manuais tendem a fazer o "caminho feliz").
Os testes podem ser estruturais (caixa branca), funcionais (caixa preta) ou de regressão (testes que verificam que o resultado final não mudou), mas para ajudar com o desenvolvimento dos testes unitários existem algumas técnicas de cobertura de código:
- Partição em classes de equivalência (Equivalence class partitioning) - usar amostragem de cada possível valor que os parâmetros de entrada podem assumir
- Análise de valores limite (Boundary Value Analysis) - nestes testes deve-se conferir os valores limites do software, onde há alterações de decisão
- Transição de estados (State Transition Testing) - utilizado para testar as chamadas máquinas de estados e conferir que as transições estão acontecendo corretamente;
- Tabela de decisão (Decision Table) - tabela com as variáveis como condições e quais ações tomar baseando-se em seus resultados, para verificar que estas sequências funcionam;
- Testes Empareados (Pairwise Testing) - para cada par de parâmetros de entrada de um sistema, testa-se todas as combinações destes parâmetros;
2-) Testes de Sistemas (desenvolvedor);
Verificações com o sistema funcionando ou testes de partes integradas e não mais de funções individuais. Pode-se fazer uma integração incremental ou total em cada etapa de testes.
Já para os testes de integração, é bom contar com algumas técnicas um pouco mais amplas:
Integração Não-Incremental que usa a abordagem Big-Bang - já integra todo o software e testa ele todo integrado;
Integração Incremental onde o programa é construído e testado em pequenos segmentos e cada vez se agrega uma parte maior do software;
Integração Top-Down - integra e testa de cima para baixo;
Integração Botton-Up - integra e testa de baixo para cima;
3-) Validação (testador independente);
Execução de roteiros de validação mesmo. E como chegamos na hora de validar o sistema como um todo, é necessário conhecermos um pouco mais do que é necessário se considerar para garantir a qualidade do software. Segundo a ISO/IEC 9126 temos as seguintes características gerais para levar em consideração:
- Funcionalidade (satisfaz as necessidades?);
- Confiabilidade (é imune a falhas e estável?);
- Usabilidade (é fácil de usar?);
- Eficiência (é rápido e eficiente?);
- Manutenibilidade (é fácil de alterar e de manter?);
- Portabilidade (é fácil de ser utilizado em outro ambiente?);
4-) Testes de Aceitação (usuário final/gerente de produto);
Deixar o produto nas mãos deste usuário para validar as funcionalidades novas, pode encontrar outros problemas, mas não há roteiro envolvido.
Já escrevi sobre este assunto algumas vezes e podem encontrar outras matérias sobre testes no meu blog.
domingo, 2 de agosto de 2009
Análise de Requisitos
Já houve um tempo em que os usuários não entendiam a magia que acontecia por trás dos sistemas de software. Eles podiam não entender como se dava o desenvolvimento do software, não conseguem especificar muito bem o que desejam do software e era muito dificil desenvolver algo sem saber exatamente o que deveria ser feito.
Então muitas técnicas surgiram e atualmente as principais técnicas de análise de requisitos consistem em fazer entrevistas com os stakeholders para se melhorar todos os requisitos, procurando remover contradições, priorizar os requisitos, permitir que eles façam a escolha também do que pode ser feito com relação aos custos.
Em alguns casos, se for julgado necessário, é possível se fazer uma reunião com todos os interessados para se definir o escopo/custo geral, principalmente quando cada uma das partes deseja algo diferente e precisam entrar em um acordo.
A forma comum de se documentar isso é por meio de contrato. E mais do que a lista de funcionalidades que pode ser muito longa, se propõe uma lista de objetivos mensuráveis que deve ser alcançada com protótipos o quanto antes, para que estes objetivos maiores possam ser atingidos.
Outras duas técnicas muito conhecidas para ajudar a exemplificar e facilitar a visualisação deste software final são a prototipação e os casos de uso para ajudar na especificação dos requisitos.
O problema é que a prototipação acabava gerando uma certa ansiedade e sensação de que o software seria mais fácil de implementar do que seria de verdade e acabava gerando bastante desgaste. Também acabavasse recorrendo ao uso do protótipo como produto final, o que poderia implicar em diversos outros riscos e também poderiam passar muito tempo apenas desenvolvendo um protótipo que poderia ser descartado.
Quanto aos casos de uso, é uma técnica que acaba simplificando muito o software para mostrar um cenário de como seria as interações do usuário com o sistema. Mas como também não diz nada sobre a lógica que deve andar por trás do software, pode ser mal interpretado nas estimativas de prazos e esforço.
Agora que o sistema está melhor especificado, acabou-se, certo? Não, claro que não. É importante também se poder acompanhar com os stakeholders se o projeto está indo na direção correta, mais um ponto para metodologias ágeis de desenvolvimento, que acabam gerando mais versões que podem voltar a ser discutidas e revisadas...
Então muitas técnicas surgiram e atualmente as principais técnicas de análise de requisitos consistem em fazer entrevistas com os stakeholders para se melhorar todos os requisitos, procurando remover contradições, priorizar os requisitos, permitir que eles façam a escolha também do que pode ser feito com relação aos custos.
Em alguns casos, se for julgado necessário, é possível se fazer uma reunião com todos os interessados para se definir o escopo/custo geral, principalmente quando cada uma das partes deseja algo diferente e precisam entrar em um acordo.
A forma comum de se documentar isso é por meio de contrato. E mais do que a lista de funcionalidades que pode ser muito longa, se propõe uma lista de objetivos mensuráveis que deve ser alcançada com protótipos o quanto antes, para que estes objetivos maiores possam ser atingidos.
Outras duas técnicas muito conhecidas para ajudar a exemplificar e facilitar a visualisação deste software final são a prototipação e os casos de uso para ajudar na especificação dos requisitos.
O problema é que a prototipação acabava gerando uma certa ansiedade e sensação de que o software seria mais fácil de implementar do que seria de verdade e acabava gerando bastante desgaste. Também acabavasse recorrendo ao uso do protótipo como produto final, o que poderia implicar em diversos outros riscos e também poderiam passar muito tempo apenas desenvolvendo um protótipo que poderia ser descartado.
Quanto aos casos de uso, é uma técnica que acaba simplificando muito o software para mostrar um cenário de como seria as interações do usuário com o sistema. Mas como também não diz nada sobre a lógica que deve andar por trás do software, pode ser mal interpretado nas estimativas de prazos e esforço.
Agora que o sistema está melhor especificado, acabou-se, certo? Não, claro que não. É importante também se poder acompanhar com os stakeholders se o projeto está indo na direção correta, mais um ponto para metodologias ágeis de desenvolvimento, que acabam gerando mais versões que podem voltar a ser discutidas e revisadas...
Assinar:
Postagens (Atom)