Áreas de Conhecimento segundo o SWEBOK

O SWEBOK é um guia de uso e aplicação das melhores práticas de Engenharia de Software, informado, sensato e razoável. Ele foi desenvolvido com conhecimentos
recolhidos no período de 4 décadas e revisado por inúmeros profissionais de diversos países envolvidos com a Engenharia de Software. Seu principal objetivo foi estabelecer um conjunto apropriado de critérios e normas para a prática profissional da Engenharia de Software. Neste guia, a Engenharia de Software foi dividida em 10 áreas de conhecimentos, também conhecidas por KAs (Knowledge Areas), que serão descritas na seqüência (SWEBOK, 2004).

1 Requisitos de Software
Os requisitos expressam a necessidade e restrições colocadas sobre o produto de software que contribuem para a solução de algum problema do mundo real. Esta área envolve elicitação, análise, especificação e validação dos requisitos de software (SWEBOK, 2004).
Segundo Breitman e Sayão (2005), os requisitos de software são classificados em:
· Requisitos funcionais: correspondem a funcionalidade do software e o que o sistema deve fazer;
· Requisitos não funcionais: expressam restrições e características que o software deve atender ou ter;
· Requisitos inversos: definem estados e situações que nunca podem acontecer.
Pressman (2002) cita que “se você não analisa, é altamente provável que construa uma solução de software muito elegante que resolve o problema errado”. Esta
atitude pode resultar em perda de tempo e dinheiro, pessoas frustradas e clientes insatisfeitos.

2 Design de Software
Segundo o SWEBOK (2004), esta área envolve definição da arquitetura, componentes, interfaces e outras características de um sistema ou componente. Visualizado como um processo, esta área é uma etapa do ciclo de vida da Engenharia de Software, onde os requisitos são analisados para produzir uma descrição da arquitetura do software. Para Pressman (2002), design de software "é um processo iterativo através do qual os requisitos são traduzidos num documento para construção do software."

3 Construção de Software
Refere-se a implementação do software, verificação, testes de unidade, testes de integração e debugging. Esta área está envolvida com todas as áreas de conhecimento, porém, está fortemente ligada às áreas de Design e Teste de Software, pois o processo de construção abrange significativamente estas duas áreas (SWEBOK, 2004). As áreas correlatas à construção de software, segundo o SWEBOK (2004) são:

· Fundamentos: minimizar a complexidade, antecipar mudanças, construir para verificar e padrões de construção;
· Gerenciamento da construção: modelos, planejamento e métricas;
· Considerações práticas: design, linguagens, codificação, testes, reutilização, qualidade e integração.

É importante que as funcionalidades do software sejam testadas durante todo o processo de desenvolvimento, não deixando apenas para a etapa de testes.

4 Teste de Software
Teste de software é uma atividade executada para avaliar a qualidade do produto, buscando identificar os defeitos e problemas existentes (SWEBOK, 2004).
Para Pressman (2002), "teste de software é um elemento crítico da garantia de qualidade de software e representa a revisão final da especificação, projeto e geração de código."
Segundo Coelho (2005) os tipos de teste são:
· Teste funcional: verifica as regras de negócio, condições válidas e inválidas;
· Teste de recuperação de falhas: as falhas são provocadas diversas vezes a fim de verificar a eficiência da recuperação;
· Teste de desempenho: verifica o tempo de resposta e processamento para configurações diferentes;
· Teste de segurança e controle de acesso: verifica a funcionalidade dos mecanismos de proteção de acesso e de dados;
· Teste de interfaces com o usuário: verifica navegação, consistência e padrões;
· Teste de volume: verifica até aonde o software suporta.
A etapa de teste de software é relevante para que os erros possam ser encontrados e corrigidos antes que o software seja entregue ao cliente.

5 Manutenção de Software
Esta área de conhecimento é definida como a totalidade das atividades requeridas para fornecer suporte custo-efetivo a um sistema de software, que pode ocorrer antes ou depois da entrega. Antes da entrega do software são realizadas atividades de planejamento e depois, modificações são feitas com o objetivo de corrigir falhas, melhorar o desempenho ou adaptá-las a um ambiente externo (SWEBOK, 2004). Os tipos de modificações durante a fase de manutenção, segundo Pressman (2002) são:
· Manutenção corretiva: modifica o software para corrigir erros;
· Manutenção adaptativa: altera o software para acomodar mudanças no seu ambiente externo;
· Manutenção perfectiva: aprimora o software (solicitações do cliente);
· Manutenção preventiva (reengenharia): modifica o software a fim de torná-los mais fáceis de serem corrigidos, adaptados e melhorados.

Em torno de 60% do esforço despendido por uma organização de desenvolvimento é referente à manutenção de software. Este percentual continua
crescendo à medida que mais softwares são produzidos. Manutenção de software não é só concertar erros. Apenas 20% do trabalho de manutenção é referente à correção de falhas e, os outros 80% refere-se à adaptações ao ambiente externo e a melhorias solicitadas pelos usuários (PRESSMAN, 2002).

6 Gerenciamento de Configuração de Software
Conforme Cunha et al (2004), o GCS (Gerenciamento de Configuração de Software) é um processo que provê recursos para a identificação, controle da evolução e auditagem dos artefatos de software criados durante o desenvolvimento do projeto. De grosso modo, é o controle de versões do software. A finalidade do GCS é estabelecer e manter a integridade dos produtos de software durante todo seu ciclo de vida (SWEBOK, 2004):
· Identificar a configuração do software em um dado momento;
· Controlar sistematicamente as mudanças de configuração;
· Manter a integridade e a rastreabilidade da configuração ao longo do ciclo de vida do software;
· Controlar a integridade dos artefatos compostos, levando em conta cada um dos componentes do software;
· Registrar e controlar o estado do processo de alteração.

Porém, sua aplicação em empresas de desenvolvimento de software é complexa, e às vezes inviabilizada pelos gastos. Uma forma de contornar isso é desenvolver uma metodologia de gerenciamento de configuração que leve em conta somente aspectos relevantes para a realidade da empresa, descartando aqueles que são menos utilizados.

7 Gerenciamento de Engenharia de Software
Segundo SWEBOK (2004), Gerenciamento de Engenharia pode-se definir como a aplicação das atividades de gerenciamento: planejamento, coordenação, medição,
monitoração, controle e documentação, garantindo que o desenvolvimento e a gerência de software sejam sistemáticos, disciplinados e qualificados.
O Gerenciamento de Engenharia é tratado sob dois aspectos:
· Engenharia de Processo: refere-se às atividades empreendidas para geração de políticas, padrões e objetivos organizacionais consistentes;
· Engenharia de Mensuração: refere-se à atribuição de valores e rótulos às atividades referentes à Engenharia de Software.

O gerenciamento de processo e a mensuração são importantes em todas as área de conhecimento, mas o Gerenciamento de Engenharia trata esses aspectos de forma
mais direta. Um grande aliado desta área de conhecimento é o Gerenciamento de Projetos, que pode ser visto a seguir.

7.1 Gerenciamento de Projetos de Software
Projeto é um empreendimento temporário, de elaboração progressiva e com o objetivo de criar um produto ou serviço único (PMBOK, 2004).
· Temporário: o projeto possui início e fim bem definidos e pode ser de curta ou longa duração. O projeto chega ao fim quando os seus objetivos são atingidos;
· Elaboração progressiva: o desenvolvimento ocorre em etapas e continua por incrementos;
· Produto ou serviço único: cada projeto é exclusivo.

Segundo o PMBOK (2004), o gerenciamento de projetos "é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de
atender aos seus requisitos". É realizado através de cinco grupos de processos: iniciação, planejamento, execução, monitoramento e controle, e encerramento.
Para Pressman (2002), “a gestão do projeto envolve o planejamento, a monitoração e controle do pessoal, processo e eventos que ocorrem à medida que o
software evolui de um conceito preliminar para uma implementação operacional". O gerenciamento de projetos auxilia as organizações a atenderem as
necessidades de seus clientes, padronizando tarefas do dia a dia e reduzindo o número de tarefas, que muitas vezes são esquecidas (PMI-SC, 2006).
Por fim, gerenciar projetos é manter o equilíbrio entre escopo, qualidade, custos, recursos e tempo (PMBOK, 2004). É papel do gerente de projetos avaliar os riscos e impactos associados a qualquer mudança em um desses fatores.

8 Engenharia de Processo de Software
A Engenharia de Processo pode ser interpretada como uma visão geral sobre questões relacionadas ao processo de Engenharia de Software, principalmente as atividades relacionadas à definição, implementação, avaliação, mensuração, gerenciamento, mudanças e melhorias do processo de ciclo de vida de software (SWEBOK, 2004). O objetivo da Engenharia de Processo de Software é implementar processos novos e melhores, seja no escopo individual, de projeto ou organizacional.

9 Ferramentas e Métodos de Software
Ferramentas de desenvolvimento de software são ferramentas criadas para auxiliar no ciclo de vida do software. Essas ferramentas normalmente automatizam algumas atividades do processo de desenvolvimento, fazendo com que o analista concentre-se nas atividades que exigem maior trabalho intelectual (SWEBOK, 2004). Métodos de Engenharia de Software impõe estrutura sobre a atividade de desenvolvimento e manutenção de software com o objetivo de torná-la sistemática e mais propensa ao sucesso (SWEBOK, 2004). Esta área de conhecimento tem como objetivo pesquisar ferramentas e métodos que aumentem a produtividade dos desenvolvedores enquanto reduzem a ocorrência de falhas no desenvolvimento (FERNANDES, 2003).

10 Qualidade de Software
A qualidade de software não pode ser entendida como perfeição. Qualidade é um conceito multidimensional, realizado por um conjunto de atributos, representando vários aspectos relacionados ao produto: desenvolvimento, manutenção e uso. Qualidade é algo factível, relativo, dinâmico e evolutivo, adequando-se ao nível dos objetivos a serem atingidos (SIMÃO, 2002). Um dos principais objetivos da Engenharia de Software é melhorar a qualidade
dos produtos de software, ela visa estabelecer métodos e tecnologias para construir produtos de software de qualidade dentro dos limites de tempo e recursos disponíveis. A qualidade de software está diretamente ligada com a qualidade do processo através do qual o software é desenvolvido, portanto, para se ter qualidade em um produto de software é necessário ter um processo de desenvolvimento bem definido, que deve ser documentado e acompanhado (SWEBOK, 2004).
A avaliação da qualidade de produtos de software normalmente é feita através de modelos de avaliação de qualidade. Esses modelos descrevem e organizam as
propriedades de qualidade do produto em avaliação. Os modelos de avaliação mais aceitos e usados no mercado são:
· CMMI (Capability Maturity Model Integration), proposto pelo CMM (Capability Maturity Model);
· Norma ISO/IEC 9126, proposta pela ISO (International Organization for Standardization).

As organizações desenvolvedoras desses modelos de qualidade fornecem selos de qualidade para as empresas que se submetem à avaliações e estiverem dentro dos
padrões propostos. Esses selos são muito valorizados pelas empresas que compram software, e representam um diferencial competitivo no mercado. Porém, nem todas as empresas têm condições financeiras de bancar os custos de uma aquisição de um selo de qualidade, pois implantar um processo de qualidade em uma empresa envolve custos elevados. Contudo, é possível implantar boas práticas e desenvolver um processo de desenvolvimento organizado adaptando modelos de desenvolvimento conhecidos, despendendo menos recursos e provendo um mínimo de sistematização no desenvolvimento de software, a fim de se ter maior qualidade.

Enjoy!

SWEBOK, PMBOK, BABOK & Outros BOKs

A área de TI cada dia conta com mais (e melhores) corpos de conhecimento para vários papéis de engenharia de software, gerência e outras áreas. Compilo aqui um conjunto de BOKs de renome reconhecido e de grande valor para projetos de TI.

    * PMBOK: Clássico corpo de conhecimento do PMI. Atualmente em sua terceira edição (inclusive em português), compila as melhores práticas para a gerência de projetos para as áreas de gerência integrada, de escopo, qualidade, custo, prazo, recursos humanos, aquisições, riscos e comunicações. Outros excelentes corpos de conhecimento do PMI incluem o corpo de conhecimento para gerência de portfólios de projetos e o corpo de conhecimento para gerência de programas (conjunto de projetos relacionados em um tema).

    * SWEBOK: Iniciativa de grande qualidade do IEEE, traz um excelente conjunto de referências para informações primárias sobre requisitos, desenho, construção, implementação, qualidade de software, gerência de projeto, processos de software, ferramentas e métodos.
 

    * BABOK: Corpo de conhecimento para modelagem de processos de negócio do Instituto Internacional de Analistas de Negócio.
 

    * EABOK: Corpo de conhecimento de arquiteturas corporativos do MITRE. Outros corpos de conhecimento sobre arquitetura corporativa incluem o DODAF (do Departamento de Defesa Americano), MODAF (Governo Inglês), o SEI Feature Oriented Domain Analysis, o TOGAF ( do Open Group) e talvez o mais conhecido deles, o Zachman Framework.
 

    * Usability Body of Knowledge: Corpo de conhecimento de usabilidade da associação de professionais de usabilidade.

Enjoy!

Software

Para que se possa obter a compreensão do que é software (e, em última análise, uma compreensão da engenharia de software), é importante examinar as características do software que o tornam diferente das outras coisas que os seres humanos constroem. Quando o hardware é construído, o processo criativo humano (análise, projeto, construção e teste) é imediatamente traduzido numa forma física. Se construimos um novo computador, nossos esboços iniciais, desenhos de projeto formais e protótipo em forma de breadboard (arranjo experimental de circuitos eletrônicos) evoluem para um produto físico (chips VLSI, placas de circuito, fontes de energia etc.). O software é um elemento de sistema lógico, e não físico. Portanto, o software tem características que são consideravelmente diferentes das do hardware.

1. O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico

Não obstante existam algumas semelhanças entre o desenvolvimento de software e a manufatura de hardware, as duas atividades são fundamentalmente diferentes. Em ambas atividades, a alta qualidade é obtida mediante um bom projeto, mas a fase de manufatura do hardware pode introduzir problemas de qualidade que inexistem (ou são facilmente corrigidos) para o software. Ambas atividades dependem de pessoas, mas a relacão entre as pessoas envolvidas e o trabalho executado é inteiramente diferente. Ambas atividades exigem a construção de um "produto", mas as abordagens são muito diferentes. Os custos do software estão concentrados no trabalho de engenharia. Isto significa que os projetos de software não podem ser geridos como se fossem projetos de manufatura. No decorrer da década passada, o conceito de "fábrica de software" foi discutido na literatura [1,2]. Torna-se importante observar que este termo não implica que a manufatura de hardware e o desenvolvimento de software sejam equivalentes. Ao contrário, o conceito de fábrica de software recomenda o uso de ferramentas automatizadas para o desenvolvimento de software.

2. O software não se "desgasta"

A Figura 1 mostra o índice de falhas como uma função do tempo para o hardware. A relação, muitas vezes chamada "curva da banheira", indica que o hardware exibe índices de falhas relativamente elevados logo no começo de seu ciclo de vida (estas falhas frequentemente são atribuídas a defeitos de projeto e manufatura); os defeitos são corrigidos e o indice de falhas cai para um nível estável (esperançosamente, muito baixo) durante certo período de tempo. À medida que o tempo passa, entretanto, o índice de falhas eleva-se novamente conforme os componentes de hardware sofrem os efeitos cumulativos de poeira, vibração, abuso, temperaturas extremas e muitos outros males ambientais. Colocado de maneira simples o hardware começa a se desgastar.

O software não é sensível aos problemas ambientais que fazem com que o hardware se desgaste. Teoricamente, portanto, a curva do índice de falhas para o software assumiria a forma representada na Figura 2. Defeitos não descobertos provocarão elevados índices de falhas no começo da vida de um programa. Porém esses são corrigidos (espera-se que novos erros não sejam introduzidos) e a curva achata-se, como mostra a Figura 2. Esta figura representa de forma grosseira e simplificada os modelos de falhas reais para o software. Entretanto fica claro que o software não se desgasta. Todavia se deteriora!

Esta aparente contradição pode ser mais bem explicada considerando a Figura 3. Durante sua vida, o software enfrentará mudancas (manutenção). Quando estas são feitas, é provável que novos defeitos sejam introduzidos, fazendo com que a curva do índice de falhas apresente picos, como mostrado na Figura 3:

Outro aspecto do uso ilustra a diferença entre o hardware e o software. Quando se desgasta, um componente de hardware é substituído por uma "peça de reposição. Não existem peças de reposição para o software. Toda falha de software indica um erro de projeto ou no processo por meio do qual o projeto foi traduzido em código executável por máquina. Portanto a manutenção do software envolve consideravelmente mais complexidade do que a manutenção de hardware.

3. A maioria dos software é feita sob medida em vez de ser montada a partir de componentes existentes.

Consideremos a maneira segundo a qual o hardware de controle para um produto baseado em microprocessadores é projetado e construído. O engenheiro de projetos desenha um esquema simples do circuito digital, faz algumas análises fundamentais para garantir que a função adequada seja conseguida e depois vai a estante onde existm catálogos de componenentes digitais. Cada circuito integrado (CI ou chip) tem uma numeração de peça, uma função definida e validada, uma interface bem definida e um conjunto padrão de diretrizes de integração. Depois que cada componente é escolhido, o hardware pode ser encomendado. Infelizmente, os projetistas de software não podem permitir-se ao que acabamos de descrever. Com poucas exceções, não existem catálogos de componentes de software. É possível encomendar software não destinado à publicação, mas somente como uma unidade completa, não como componente que possa ser montado novamente em novos programas, embora esta situação esteja em mudança com a difusão do uso de programação orientada a objeto, cujo resultado são as "CIs de Software". Ainda que muita coisa tenha sido escrita sobre reusabilidade de software, somente agora começam a aparecer as primeiras tentativas bem sucedidas.

COMPONENTES DO SOFTWARE

O software de computador é uma informação que existe em duas formas básicas: componentes não executáveis em máquina e componentes executáveis em máquina. Para o propósito de nossa discussão aqui, somente os componenentes de software que levam diretamente a instruções executáveis em máquina serão apresentados. Os componentes de software são criados por meio de uma série de conversões que mapeiam as exigências de clientes para código executável em máquina. Um modelo (ou protótipo) das exigências é convertido num projeto. O projeto de software é convertido em uma linguagem que especifica a estrutura de dados do software, os atributos procedimentais e os requisitos relacionados. A forma de linguagem é processada por um tradutor que a converte em instruções executáveis em máquina. A reusabilidade é uma caracerística importante de um componente de software de alta qualidade [3]. Ou seja, o componente deve ser projetado e implementado de forma que possa ser reusado em muitos programas diferentes. Na década de 1960, foram construídas bibliotecas de sub-rotinas científicas que eram reusáveis num amplo conjunto de aplicações científicas e de engenharia. Estas bibliotecas de sub-rotinas reusavam algoritmos bem definidos efetivamente, mas tinham um domínio de aplicação limitado. Atualmente ampliamos nossa visão do reuso a fim de envolver não apenas algoritmos mas também estruturas de dados. Um componente resusável na década de 1990 engloba tanto dados como processamento num único pacote (às vezes chamado classe ou objeto), possibilitando que o engenheiro de software crie novas aplicações a partir de partes reusáveis. Por exemplo as interfaces interativas de hoje frequentemente são construídas utilizando-se componentes reusáveis que possibilitam a criação de janelas gráficas, menus pull-down e uma ampla variedade de mecanismos de interação. As estruturas de dados e detalhes de processamento exigidos para se construir a interface com os usuários estão contidas numa biblioteca de componentes reusáveis pra construção de interfaces.

Os componentes de software são construídos usando uma linguagem de programação que tem um vocabulário limitado, uma gramática explicitamente definita e regras de sintaxe e semântica bem formadas. Esses atributos são essenciais para a tradução por máquina. As formas de linguagem em uso são linguagens de máquina, linguagens de alto nível e linguagens não-procedimentais. A linguagem de máquina é uma represetação simbólica do conjunto de instruções da Unidade Central de Processamento (CPU - Central Processing Unity). Quando um bom desenvolvedor de software produz um programa bem documentado, capaz de sofrer manutencção, a linguagem de máquina pode fazer um uso extremamente eficiente da memória e otimizar a velocidade de execução do programa. Quando um programa é projetado pobremente e tem pouca documentação, a linguagem de máquina é um pesadelo. As linguagens de alto nível permitem que o desenvolvedor de software e o programa sejam independentes da máquina. Quando é usado um tradutor mais sofisticado, o vocabulário, a gramática, a sintaxe e a semântica de uma linguagem de alto nível podem ser muito mais sofisticados do que as linguagens de nível de máquina. De fato, os compiladores e os interpretadores de linguagem de alto nível produzem como saída uma linguagem de máquina. Não obstante centenas de linguagens de progamação estejam em uso atualmente pouco mais do que 10 linguagens de programação de alto nível são amplamente usadas na indústria. Linguagens tais como o COBOL e FORTRAN continuam tendo um uso generalizado quase 30 anos depois de sua introdução. Linguagens de programação modernas tais como Pascal, C e Ada estão sendo amplamente usadas. Linguagens orientadas a objetos, tais como C++, Object Pascal, Eiffel e outras estão conquistando entuasiásticos seguidores. Linguagens especializadas tais como APL, LISP, OPS5, Prolog e linguagens descritivas podem para redes neurais artificiais estão conquistando maior aceitação à medida novas abordagens de aplicação saem do laboratório para o uso prático. As linguagens de máquina, as linguagens montadoras (Assembly) e as linguagens de programação de alto nível frequentemente são citadas como "as tres primeiras gerações" das linguagens de computador. Com todas estas linguagens, o programador deve preocupar-se tanto com a especificação da estrutura de informações como com o controle do programa em si. Daí as linguagens das três primeiras geracões serem domiadas linguagens procedimentais. No decorrer da última década, um grupo de linguagens de quarta geração, ou não-procedimentais, foi introduzida. Em vez de exigir que o desenvolvedor de software especifique detalhes de procedimentos, a linguagem nao-procedimental subentendo um programa "especificando o resultado desejado, em vez de especificar a ação exigida para se conseguir esse resultado" [4]. O software de apoio converte a especificação do resultado numprogram executável em máquina.

Texto extraído com pequenas adaptações de:

Presman, R.S.; Engenharia de Software, Makron books, S.P., 1995, pags. 13-19

TABACARIA

Não sou nada.
Nunca serei nada.
Não posso querer ser nada.
À parte isso, tenho em mim todos os sonhos do mundo.

Janelas do meu quarto,
Do meu quarto de um dos milhões do mundo que ninguém sabe quem é
(E se soubessem quem é, o que saberiam?),
Dais para o mistério de uma rua cruzada constantemente por gente,
Para uma rua inacessível a todos os pensamentos,
Real, impossivelmente real, certa, desconhecidamente certa,
Com o mistério das coisas por baixo das pedras e dos seres,
Com a morte a por umidade nas paredes e cabelos brancos nos homens,
Com o Destino a conduzir a carroça de tudo pela estrada de nada.

Estou hoje vencido, como se soubesse a verdade.
Estou hoje lúcido, como se estivesse para morrer,
E não tivesse mais irmandade com as coisas
Senão uma despedida, tornando-se esta casa e este lado da rua
A fileira de carruagens de um comboio, e uma partida apitada
De dentro da minha cabeça,
E uma sacudidela dos meus nervos e um ranger de ossos na ida.

Estou hoje perplexo, como quem pensou e achou e esqueceu.
Estou hoje dividido entre a lealdade que devo
À Tabacaria do outro lado da rua, como coisa real por fora,
E à sensação de que tudo é sonho, como coisa real por dentro.

Falhei em tudo.
Como não fiz propósito nenhum, talvez tudo fosse nada.
A aprendizagem que me deram,
Desci dela pela janela das traseiras da casa.
Fui até ao campo com grandes propósitos.
Mas lá encontrei só ervas e árvores,
E quando havia gente era igual à outra.
Saio da janela, sento-me numa cadeira. Em que hei de pensar?

Que sei eu do que serei, eu que não sei o que sou?
Ser o que penso? Mas penso tanta coisa!
E há tantos que pensam ser a mesma coisa que não pode haver tantos!
Gênio? Neste momento
Cem mil cérebros se concebem em sonho gênios como eu,
E a história não marcará, quem sabe?, nem um,
Nem haverá senão estrume de tantas conquistas futuras.
Não, não creio em mim.
Em todos os manicômios há doidos malucos com tantas certezas!
Eu, que não tenho nenhuma certeza, sou mais certo ou menos certo?
Não, nem em mim...
Em quantas mansardas e não-mansardas do mundo
Não estão nesta hora gênios-para-si-mesmos sonhando?
Quantas aspirações altas e nobres e lúcidas -
Sim, verdadeiramente altas e nobres e lúcidas -,
E quem sabe se realizáveis,
Nunca verão a luz do sol real nem acharão ouvidos de gente?
O mundo é para quem nasce para o conquistar
E não para quem sonha que pode conquistá-lo, ainda que tenha razão.
Tenho sonhado mais que o que Napoleão fez.
Tenho apertado ao peito hipotético mais humanidades do que Cristo,
Tenho feito filosofias em segredo que nenhum Kant escreveu.
Mas sou, e talvez serei sempre, o da mansarda,
Ainda que não more nela;
Serei sempre o que não nasceu para isso;
Serei sempre só o que tinha qualidades;
Serei sempre o que esperou que lhe abrissem a porta ao pé de uma parede sem porta,
E cantou a cantiga do Infinito numa capoeira,
E ouviu a voz de Deus num poço tapado.
Crer em mim? Não, nem em nada.
Derrame-me a Natureza sobre a cabeça ardente
O seu sol, a sua chava, o vento que me acha o cabelo,
E o resto que venha se vier, ou tiver que vir, ou não venha.
Escravos cardíacos das estrelas,
Conquistamos todo o mundo antes de nos levantar da cama;
Mas acordamos e ele é opaco,
Levantamo-nos e ele é alheio,
Saímos de casa e ele é a terra inteira,
Mais o sistema solar e a Via Láctea e o Indefinido.

(Come chocolates, pequena;
Come chocolates!
Olha que não há mais metafísica no mundo senão chocolates.
Olha que as religiões todas não ensinam mais que a confeitaria.
Come, pequena suja, come!
Pudesse eu comer chocolates com a mesma verdade com que comes!
Mas eu penso e, ao tirar o papel de prata, que é de folha de estanho,
Deito tudo para o chão, como tenho deitado a vida.)

Mas ao menos fica da amargura do que nunca serei
A caligrafia rápida destes versos,
Pórtico partido para o Impossível.
Mas ao menos consagro a mim mesmo um desprezo sem lágrimas,
Nobre ao menos no gesto largo com que atiro
A roupa suja que sou, em rol, pra o decurso das coisas,
E fico em casa sem camisa.

(Tu que consolas, que não existes e por isso consolas,
Ou deusa grega, concebida como estátua que fosse viva,
Ou patrícia romana, impossivelmente nobre e nefasta,
Ou princesa de trovadores, gentilíssima e colorida,
Ou marquesa do século dezoito, decotada e longínqua,
Ou cocote célebre do tempo dos nossos pais,
Ou não sei quê moderno - não concebo bem o quê -
Tudo isso, seja o que for, que sejas, se pode inspirar que inspire!
Meu coração é um balde despejado.
Como os que invocam espíritos invocam espíritos invoco
A mim mesmo e não encontro nada.
Chego à janela e vejo a rua com uma nitidez absoluta.
Vejo as lojas, vejo os passeios, vejo os carros que passam,
Vejo os entes vivos vestidos que se cruzam,
Vejo os cães que também existem,
E tudo isto me pesa como uma condenação ao degredo,
E tudo isto é estrangeiro, como tudo.)

Vivi, estudei, amei e até cri,
E hoje não há mendigo que eu não inveje só por não ser eu.
Olho a cada um os andrajos e as chagas e a mentira,
E penso: talvez nunca vivesses nem estudasses nem amasses nem cresses
(Porque é possível fazer a realidade de tudo isso sem fazer nada disso);
Talvez tenhas existido apenas, como um lagarto a quem cortam o rabo
E que é rabo para aquém do lagarto remexidamente

Fiz de mim o que não soube
E o que podia fazer de mim não o fiz.
O dominó que vesti era errado.
Conheceram-me logo por quem não era e não desmenti, e perdi-me.
Quando quis tirar a máscara,
Estava pegada à cara.
Quando a tirei e me vi ao espelho,
Já tinha envelhecido.
Estava bêbado, já não sabia vestir o dominó que não tinha tirado.
Deitei fora a máscara e dormi no vestiário
Como um cão tolerado pela gerência
Por ser inofensivo
E vou escrever esta história para provar que sou sublime.

Essência musical dos meus versos inúteis,
Quem me dera encontrar-me como coisa que eu fizesse,
E não ficasse sempre defronte da Tabacaria de defronte,
Calcando aos pés a consciência de estar existindo,
Como um tapete em que um bêbado tropeça
Ou um capacho que os ciganos roubaram e não valia nada.

Mas o Dono da Tabacaria chegou à porta e ficou à porta.
Olho-o com o deconforto da cabeça mal voltada
E com o desconforto da alma mal-entendendo.
Ele morrerá e eu morrerei.
Ele deixará a tabuleta, eu deixarei os versos.
A certa altura morrerá a tabuleta também, os versos também.
Depois de certa altura morrerá a rua onde esteve a tabuleta,
E a língua em que foram escritos os versos.
Morrerá depois o planeta girante em que tudo isto se deu.
Em outros satélites de outros sistemas qualquer coisa como gente
Continuará fazendo coisas como versos e vivendo por baixo de coisas como tabuletas,

Sempre uma coisa defronte da outra,
Sempre uma coisa tão inútil como a outra,
Sempre o impossível tão estúpido como o real,
Sempre o mistério do fundo tão certo como o sono de mistério da superfície,
Sempre isto ou sempre outra coisa ou nem uma coisa nem outra.

Mas um homem entrou na Tabacaria (para comprar tabaco?)
E a realidade plausível cai de repente em cima de mim.
Semiergo-me enérgico, convencido, humano,
E vou tencionar escrever estes versos em que digo o contrário.

Acendo um cigarro ao pensar em escrevê-los
E saboreio no cigarro a libertação de todos os pensamentos.
Sigo o fumo como uma rota própria,
E gozo, num momento sensitivo e competente,
A libertação de todas as especulações
E a consciência de que a metafísica é uma consequência de estar mal disposto.

Depois deito-me para trás na cadeira
E continuo fumando.
Enquanto o Destino mo conceder, continuarei fumando.

(Se eu casasse com a filha da minha lavadeira
Talvez fosse feliz.)
Visto isto, levanto-me da cadeira. Vou à janela.
O homem saiu da Tabacaria (metendo troco na algibeira das calças?).
Ah, conheço-o; é o Esteves sem metafísica.
(O Dono da Tabacaria chegou à porta.)
Como por um instinto divino o Esteves voltou-se e viu-me.
Acenou-me adeus, gritei-lhe Adeus ó Esteves!, e o universo
Reconstruiu-se-me sem ideal nem esperança, e o Dono da Tabacaria sorriu.

    Álvaro de Campos, 15-1-1928

FERNANDO
PESSOA Poesias de
Álvaro de Campos

COMO NASCEM OS CIENTISTAS

(*)Retirado de: REIS, José. Educação é Investimento. São Paulo, IBRASA, 1968.

O cientista não é como o coelho de Páscoa, que pelo menos imaginariamente nasce de um ovo de chocolate, ao contrário dos outros coelhinhos. O cientista nasce exatamente como todos os outros homens, trazendo consigo as qualidades combinadas de seus pais e antepassados, e combinadas e recombinadas de tal modo que, embora afirmemos que todos os homens são iguais em seus direitos, na verdade não existe nenhum homem que seja perfeitamente igual a qualquer outro. Uma vez nascido o cientista, ou melhor, a criança que um dia se tornará cientista, sobre ela agem as muitas influências de meio, favorável umas, outras hostis. O comportamento do que vai ser um cientista, como o de qualquer outra pessoa, é produto da ação conjunta daqueles fatores que vêm dos pais - a herança - e daqueles que se acham no meio ambiente. E quando dizemos meio ambiente, queremos dizer tudo que nos cerca e entra em contato conosco, sem excluir portanto as outras pessoas. Entre estas, naturalmente, os professores.

Mas por que comecei esta história sobre como nascem os cientistas, afirmando que eles o fazem como todos os outros homens? Para deixar claro desde já que o cientista é um homem como qualquer outro, não sendo certo imaginar que a ele necessariamente corresponda algum comportamento anormal ou estranho, como o que caracteriza os "cientistas loucos" das histórias de quadrinhos e de tantas fitas de cinema. Há cientistas meio aloucados, sim, mas em qualquer outro ramo de atividades encontramos gente assim, de temperamento descontrolado, agressiva. Se levarmos mais longe esse pensamento, poderemos afirmar tranqüilamente que aquelas pessoas que lotam os sanatórios de doença mentais não são em geral cientistas. Poderá haver entre elas cientistas ou projetos de cientistas que a doença mental colheu, como pode colher qualquer outro ser humano. E também haverá algumas com mania de ser cientistas, falando como se fossem sábios, mas ainda aí haveremos de convir em que, do lado de cá das tristes paredes dos hospícios, não faltam criaturas a fingir ciência que não têm e a perturbar com ela a vida de seus semelhantes, chegando mesmo a desencaminhar os governantes, que tantas vezes se deixam levar pelos "bons de bico", ou mirabolantes homens da meia ou da falsa ciência.

Alguns psicólogos têm analisado a vida dos cientistas para ver se descobrem algum traço, ou alguns caracteres que permitam dizer com certeza ou boa probabilidade se uma pessoa tem ou não capacidade para a ciência. Esses estudos infelizmente não nos ensinam muita coisa. Pois existem cientistas de todo jeito, taciturnos ou alegres, pé de boi ou flanadores, atentos às necessidades de seu vizinho e de sua família, ou indiferentes. Ainda aí, na ciência como em tudo o mais.

Conheço cientista pontuais, quase burocráticos no rigor que se impõem na observância de horários. Dizem que Fleming, o descobridor da penicilina, era tão regular em seus hábitos que se tornava possível acertar o relógio pela hora em que entrava e saía do laboratório. Mas também existem cientistas de vida menos organizada, distraídos. Um deles, colega meu dos mais ilustres, esqueceu durante muitos dias (não sei se meses) a bagagem que trouxe do Rio, no armazém da Central do Brasil. E essa bagagem, era os móveis da casa! A família teve de arranjar-se com caixotes e mesas improvisadas até que ele fosse à Central, pagasse a taxa devida pelo armazenamento e recebesse os trastes. O mesmo colega (foi ele quem me contou a história, achando-a muito engraçada) ao voltar para casa, entrou na residência do vizinho (era um correr de casas geminadas), subiu a escada que dava para o andar de cima, foi ao banheiro e só quando descia a escada percebeu que estava em domicílio alheio, felizmente de amigo. Ao relatar-me a situação, ajuntou um pormenor: começara a desconfiar de que não estava em sua casa quando, ao apertar uma válvula, esta funcionou, surgindo água no lugar adequado. Dizem que Newton era distraído, a ponto de uma vez, tendo de cozinhar um ovo na água, colocar o relógio dentro da água e ficar com o ovo na mão, para contar os minutos. Uma caricatura cujo autor não me vem à mente, representa um sábio distraído, com a mão no queixo e o ar distante, diante de uma certa porta que costuma ser extremamente reservada, a perguntar-se: "Que é que vim fazer aqui?"

Essas coisas não acontecem apenas a cientista, embora seja natural que a eles ocorram com alguma freqüência porque andam com a cabeça cheia de raciocínios, ou sonhos (se quiserem), e por isso facilmente se perdem. Qualquer outra pessoa, porém, que esteja com a cabeça atulhada de pensamentos ou meditações, poderá comportar-se de maneira semelhante.

Se analisarmos a infância e a adolescência dos cientistas, também encontraremos muita variação. Uns desde muito novos manifestam lampejos de gênio e aferram-se a um assunto. Por causa disso não prestam atenção a outra matérias, na escola, e são tidos às vezes por travessos ou mesmo inaproveitáveis. Alguns desses meninos tiveram grandes dissabores quanto enfrentaram as bancas de exames, pois os mestres não os compreendiam. Evaristo Galois, o grande matemático, foi desse tipo. Há cientistas que, na infância, entram na categoria dos meninos prodígios, Nela se incluiu o matemático Norbet Wierner, da cibernética, que conta sua própria vida num livro chamado "Ex-Prodigy". Mas nem todo prodígio deu prodigiosas realizações no futuro. Ainda aqui o mundo da ciência não apresenta muita novidade.

Em contraste, foi aparentemente lerdo o desenvolvimento intelectual de não poucos cientistas. Entre eles podemos citar Copérnico e Faraday, dois dos grandes revolucionários da ciência.

A história de Einstein e Darwin é ilustrativa. Aos olhos de seus pais e mestres Darwin foi mau estudante; abandonou os estudos assim que soube que por herança lhe estava assegurada uma renda que dava para viver folgadamente. Se muito estudo regular é que embarcou no navio "Beagle", como naturalista, e fez longa viagem pelo mundo. Observou muito, tomou notas, guardou exemplares dos seres observados. E depois de muita meditação nas horas boas, isto é, quando não estava com dor de cabeça, nasceu a teoria da evolução.

Einstein também não se distinguiu como estudante. Melhor que Darwin, sem dúvida, mas não conseguiu passar no exame para a Politécnica de Zurique, na primeira vez. Logrou-o na segunda, mas nunca impressionou os mestres, que até lhe recomendaram mudar de profissão - diziam que era preguiçoso - acenando-lhe com a biologia ou teologia. Formou-se, mas nunca pode conquistar um título que, por sua categoria, lhe permitisse ingressar na carreira de pesquisador universitário.

Pasteur também não se distinguiu por nenhuma qualidade especial quando menino, porém Lineu, o grande naturalista, desde muito cedo fugia da escola para catar plantas.

Se investigarmos os cientistas do ponto de vista de sua origem social, é difícil afirmar que de determinadas camadas provenham necessariamente os melhores, ou mais numerosos cientistas. Algumas investigações mais antigas pareciam indicar que os cientistas vêm geralmente de pais que se encontram entre os representantes das profissões liberais, porém ainda recentemente se revelou que uma grande maioria dos mais eminentes físicos norte-americanos provém de classes rurais, algumas vezes de imigrantes de modesta condição.
O resultado não é diferente quando consideramos os cientistas segundo as raças. Se são muito mais numerosos em brancos e depois em amarelos, é porque nesses grupos se encontram melhores condições sociais para a ascensão. Como pode ser cientista um pele-vermelha ou um negro criado em condições inferiores?

A capacidade intelectual é muito complexa. Nela entram vários fatores, alguns dos quais ainda mal conhecidos. Mesmo aquilo que se chama de inteligência e se mede sob forma de quociente intelectual, está longe de ser homogêneo. Duas pessoas com o mesmo QI podem ter inteligências diferentes do ponto de vista qualitativo, isto é, inteligências que se adaptam melhor ao aproveitamento de determinadas condições do meio. Na inteligência como nas outras capacidades intelectuais entram sem dúvida fatores hereditários, porém esses fatores são muito gerais e numerosos, e de sua combinação resultam sem dúvida diferenças de comportamento intelectual que tornam uma pessoa melhor para certos trabalhos e outra para outros, embora não haja nenhuma especificidade muito rígida. Quer dizer que ninguém nasce matemático, ou que nem todo matemático tem exatamente o mesmo tipo de inteligência.

Não é então possível distinguir as tendências ou potencialidades das pessoas? É, até certo ponto. Em relação à inteligência, sabemos que aquilo que se chama de "burrice" é incompatível com ela, mas nem por isso o cientista é necessariamente super dotado em inteligência. Há cientistas de vários graus de inteligência. Além disso, capacidade intelectual não é só a inteligência que se mede como quociente intelectual. Existe, por exemplo, uma qualidade conhecida como criatividade, que o quociente intelectual não mede, mas que pode ser até certo ponto avaliada por outros meios. A criatividade exprime o poder que a pessoa tem de imaginar soluções novas, de descobrir. Ela pode ser muito alta mesmo quando a inteligência não é das mais altas.

Ora, a criança é sempre uma criança difícil. E é difícil porque, segundo Paul Torrance, que tanto tem estudado esse assunto, ela é diferente do comum das crianças, está sempre a fazer perguntas a respeito das coisas que a intrigam, procura realizar tarefas difíceis e até perigosas, absorve-se em seus pensamentos, é sincera (e as crianças costumam ser condicionadas desde o lar e depois na escola e até na igreja, salienta aquele especialista, a ser um pouco menos sincera), é acanhada e encabulada, pode parecer rude com os outros, e muita coisa mais. Uma série de dificuldades, como se vê, que os mestres podem aproveitar para melhorar, mas que também podem servir de ponto de partida. para o progresso inverso.

Deve-se ainda lembrar que a criatividade que aí se referiu não significa necessariamente a criatividade científica, esta mesma tão cheia de variações.

Daí se conclui que o importante é observar bem os meninos, desde cedo. Uns aprendem melhor quando sobre eles pesa a autoridade, que passa a lição e exige respostas. Outros aprendem melhor descobrindo por si mesmo o que lhes seria ensinado; estes últimos costumam trabalhar melhor quando o seu interesse próprio é despertado para algum problema.

Existem vários tipos de testes que ajudam a perceber a tendências, ou o tipo, da criança ou do jovem, mas tudo isso entendido sempre em termos. Para compreender o porque desta nossa cautela, basta recordar que os cientistas não se revelam todos precocemente. E nem a ciência exige de todos os mesmo total de qualidades.

Todos eles, uma vez encaminhados, podem produzir grandes coisas na ciência. Naturalmente escolherão especialidades e tipos de problemas diferentes, mas poderão chegar a grandes soluções. Não devemos pensar que a ciência é feita só pelos gênios. Há uma porção de homens médicos, porém trabalhadores, que chegam às vezes mais longe que os gênios, porque invenção é, como já se disse, 90 por cento de transpiração e dez por cento de inspiração.

Lembre-se uma vez mais que nem sempre o interesse científico aparece cedo. Muitos só se decidem pela carreira cientifica depois de terem feito um curso básico completo. Outros "vibram" logo de início.

Seja lá como for, não pode haver ciência sem um conhecimento básico, uma aprendizagem que terá de ser maior ou menor conforme o tipo de inteligência ou capacidade intelectual da pessoa. Cada vez mais difícil descobrir coisas novas, porque vamos penetrando maiores profundidades. A experiência relativamente simples de outrora não mais nos satisfaz. Queremos muito grande rigor. Mas assim mesmo, é bom lembrar que a penicilina nasceu de experiências parecidas com as do começo da microbiologia. E a reserpina lembra muito a história da digitalina.

Meu propósito era falar sobre como nascem os cientistas. Mas o melhor é falar de outra maneira: como se fazem os cientistas. Eles se fazem pelo aproveitamento inteligente dos jovens que manifestam propensão para a ciência, que no fundo é a arte de fazer perguntas à natureza. Uns gostam de perder-se em abstrações, reformulando idéias e conceitos. Outros recebem um desafio direto da natureza, sob forma de um problema que surge diante seus olhos. Outros ainda manifestam muita curiosidade e por isso enxergam dúvidas onde o comum vê coisas iguais às outras.

Desde que o mundo é mundo, quantos milhões de homens se sentaram à sombra de uma árvore em dia de sol? Muitos, sem dúvida. Mas quantos repararam em que a sombra é rendilhada de luz e que esse rendilhado é feito de círculos ou quase círculos? Alguns poucos homens. Aquele que se fixou nesse pormenor, estava vendo o que outros olhos não enxergavam. E quando procurou explicar por que a luz aparecia em manchas arredondadas, estava realizando uma operação intelectual de descoberta e de criatividade, que pouquíssimos se lembram de fazer. Quem adotou estas últimas atitudes era certamente um espírito animado do interesse científico, ainda que sem conhecimento básico científico e mesmo que chegasse a conclusões inteiramente erradas.

A criança é curiosa, o adulto nem sempre é. Isto quer dizer que em algum momento de sua vida ele perdeu a curiosidade. Quando se trata da curiosidade muito grande, que leva a criança e depois o menino a investigar por si mesmo a razão de ser daquilo que ele vê, cuidado! Aí pode estar o embrião de um cientista, e o mau ensino pode abafá-lo, destruí-lo. Quando se trata de um menino que não aceita a afirmação do livro ou do mestre, mas levanta dúvidas e faz hipóteses suas, cuidado! Aí pode estar um cientista em potencial. Quando o menino se dedica desde cedo a colecionar, não por simples "febre" imigratória, mas com empenho real, aí pode estar o germe de um naturalista. E assim por diante.

A responsabilidade dos mestres nesse trabalho é muito grande porque o sistema de ensino pode levar o professor a atrapalhar o aluno e a destruir nele o interesse pela ciência. Tudo o que for possível fazer para que as qualidades interiores dos jovens se patenteiem, deve ser feito. As feiras de ciência, favorecendo, como os clubes de ciência, o aprendizado pela descoberta, são extremamente favoráveis à formação de cientistas.
Podemos afirmar sem medo de errar que o cientista não nasce feito. Ele se faz depois de nascido. Ninguém é cientista nato porque seus pais são brancos, e não pretos, de olhos azuis e não castanhos, ou porque esses pais são cientistas eles mesmos. Lembremo-nos de Pasteur, de Faraday, de Dalton, tudo gente nascida humildemente e crescida na humildade. E lembremo-nos igualmente do jovem e pobre PerKinn, que soube virar a seu favor um erro de experiência e fazer de uma reação que não "dera certo" o ponto de partida para a descoberta dos corantes de anilina.

É claro que o ambiente em que a criança vive tem importância. Se ela cresce em uma casa onde freqüentemente se discutem problemas, se trocam idéias e se adotam atitudes críticas, já leva uma grande ajuda. Mas nem por isso o gênio deixa de revelar-se mesmo quando sobre ela pesa a ignorância dos pais. Quando cientistas tiveram de abrir seu caminho em oposição aos pais, que lhes preparavam carreiras diferentes!

Estas considerações, por perfunctórias que sejam, bastam para salientar um fato importante: o potencial científico, existente normalmente na população de um país, é muito grande. Muitos jovens poderiam ser encaminhados para a ciência e deixam de ser por incompreensão dos pais e até mesmo dos mestres. E não há país que consiga progresso sem uma boa base de ciência, sobre a qual se implanta a técnica.

A responsabilidade dos pais é muito grande, nesse terreno. Porém maior ainda é a dos professores e a dos homens cultos em geral. A educação tem de ser um mecanismo sempre atento às manifestações vocacionais, para bem encaminhar os jovens, tendo naturalmente de adotar um conjunto de conhecimentos básicos como interesse de permitir que o poder criador de cada um se manifeste livremente.

Nas mãos do mestre ou do homem esclarecido, interessado no potencial humano, se encontra, por assim dizer, a chave da libertação do maior potencial de nosso país, como de qualquer outro: a inteligência de sua gente e seu aproveitamento adequado. São muitas as vidas de cientistas célebres em que aparece um mestre ou amigo como varinha de condão para orientar e "desencantar" um gênio que se encontrava perdido ou mesmo perseguido. Gosto de recordar um médico que se interessou por Lineu, o menino travesso que fugia da escola para catar plantas. Apresentado como aluno rebelde pela maioria dos mestres, o que causava tristeza aos pais, encontrou naquele mesmo médico a compreensão e o apoio que lhe permitiam seguir a carreira botânica e ser um dos nomes de maior brilho em todos os tempos, nas ciências naturais.

Se os cientistas nascem como todas as pessoas, não levando na testa nenhuma marca visível, cabe-nos descobrir entre os alunos, nas várias idades, aqueles que prometem realizar-se na ciência. O ensino é um meio de realização e não de aprisionamento ou abafamento das capacidades humanas.

Não é possível encerrar um assunto desse, em que tantas vezes se é obrigado a falar de alunos travessos, ou irrequietos, que eram na verdade embriões de grandes cientistas, sem uma palavra de cautela. É preciso lembrar que nem todas as crianças ou os adolescentes difíceis devem essa peculiaridade a algum traço de genialidade ou de espírito criador, que os mestres não percebam. Há uma porção de outras causas, às vezes patológicas. Por isso o professor tem de ter uma sólida formação psicológica e em cada escola se torna cada vez mais importante o papel da orientação psicológica.

E bastará o conhecimento da matéria e o conhecimento psicológico aprofundado? Acho que a essas qualidades é preciso ajuntar o amor pelo magistério – ninguém educa sem amor - e especialmente nestes trópicos menos desenvolvidos, onde tanto se desperdiça em matéria-prima humana, um grande amor, um imenso amor pela pátria.



José Reis

Arquitetura de Software

Como já li várias definições para Arquitetura de Software, decidi por criar uma:

"Arquitetura de Software é a decomposição da solução de um problema computacional orientada a(os) risco(s) e requisito(s) não funcional(is) equacionada pelo problema em questão."

De forma simples: projete a solução para prover os requisitos não funcionais e reduzir os riscos do projeto. Isso gera uma série de decisões a serem tomadas durante o projeto, envolvendo todos os elementos da decomposição da solução, mas que gera valor (benefício em tupiniquês) a longo prazo. O próximo post, a definição será explorada.

Enjoy!

Tabela de Preços - Problema e Custo de Manutenção de Computador

    * É só um ajustinho: R$ 85,00
    * Fulano faz por tanto: R$ 110,00
    * Parafuzinho: R$ 65,00
    * Quebra galho: R$ 90,00
    * Favor para amigo: R$ 70,00
    * Só uma olhadinha: R$ 90,00
    * Meu filho desprogramou: R$ 65,00
    * Eu nem mexi: R$ 70,00
    * Coisa simples: R$ 50,00
    * Deve de ser um fiozinho solto: R$ 80,00
    * Só pra ver como fica: R$ 55,00
    * É só pôr isso no lugar: R$ 85,00
    * Aparelho mexido por curioso: R$ 100,00
    * Deve ser um fuzivel: R$ 75,00
    * O aparelho não tem nada é só um "detalhezinho": R$ 90,00
    * Serviço pra ontem: R$ 60,00
    * Serviço pra já!: R$ 120,00
    * É uma pecinha solta: R$ 50,00
    * Duas pecinhas soltas: R$ 100,00
    * Só uma soldinha, até eu mesmo faria: R$ 85,00
    * Eu não confio em deixar com qualquer um, tem que ser hoje ou levo pra outro: R$ 150,00
    * Eu mesmo troquei: R$ 85,00
    * Me disseram pra instalar: R$ 90,00
    * Eu juro que não apaguei: R$ 150,00
    * Derramei em cima: R$ 95,00
    * Meu amigo que fez: R$ 120,00
    * Não lembro: R$ 165,00
    * Peguei na internet: R$ 50,00
    * Instalei do CD da revista: R$ 45,00
    * Até ontem funcionava: R$ 77,00
    * Se arrependimento matasse: R$ 320,00
    * Minha irmã que mexeu: R$ 90,00
    * Meu irmão que mexeu: R$ 120,00
    * Lavei para limpar: R$ 180,00
    * Caiu "Drento": R$ 110,00
    * Quebrô sozinho: R$ 100,00
    * Eu juro que "num fui eu": R$ 130,00
    * Me disseram que era bom: R$ 95,00
    * Tá caro: R$ 300,00
    * Vírus: R$ 130,00
    * Só mexi aqui: R$ 80,00
    * Encostei o dedo: R$ 120,00
    * Eu que fiz: R$ 100,00
    * Eu que arrumei: R$ 150,00
    * Parou de funcionar sozinho: R$ 450,00 + peças
    * O filho do vizinho entende pra caramba: R$ 92,00

Só não encontrei o famoso "Só um programinha..."

Enjoy!

Elitismo na Ciência

Stephen Dutch é geólogo e uma ativista cético. Em suas constantes discussões sobre ciência, ceticismo, evolucionismo e etc, Dutch recebe muitos emails irados como esse:

    "Estou cansado dos que se apontam como experts e de sua atitude arrogante de quem sabe tudo. Porque vocês não ficam fora de coisas das quais não sabem nada? Vocês fazem parecer que sabem tudo e o resto de nós é estúpido"

Agora Stephen Dutch jogou o pano:

    "Já vi esse script antes. Neste ponto eu deveria assumir uma postura humilde e dizer 'Tudo bem... nós não queríamos fazê-lo se sentir mal. Você é mesmo uma boa pessoa e um ser humano valioso e suas opiniões são importantes'.

    Estou cansado desse jogo.

        * Nós não somos auto-intitulados experts. Nós somos experts de verdade.

        * Não é arrogância falar sobre o que você sabe profissionalmente. É arrogância rejeitar a opinião de um expert sem possuir expertise para tal.

        * Se ouvir os experts que dizem que você está errado faz você se sentir mal ou estúpido, este é um problema seu, não nosso. Procure um analista e trabalhe a sua auto-estima. Se você pensa que isso machuca seu ego tente passar meses trabalhando em um artigo científico e depois vê-lo ser rejeitado; algo por que passam os verdadeiros experts de vez em quando.

        * Nós não sabemos tudo mas sabemos mais à respeito de nossa área de conhecimento do que outras pessoas, especialmente pessoas sem treinamento nenhum.

        * A não ser que você possua evidências verdadeiras que suportem sua opinião, elas não contam.

        * Se você ouviu algo que conflita com o que você acha que sabe e não se importou em checar a informação então você não deveria se sentir estúpido. Você é estúpido.

        * Se você quer discutir com experts mas não quer investir tempo e esforço para se tornar um expert, você não é apenas estúpido. Você é preguiçoso também.

        * Se você pensa que estou desreipetando você, você está certo. Eu não tenho nenhum respeito por quem é desinformado e que fica nervoso quando alguém o contradiz, mas é preguiçoso demais para se informar e covarde demais para suportar rejeição, crítica e a possibilidade de mudar suas conviccções. Você não é uma boa pessoa. Ninguém que é preguiçoso e covarde pode ser chamado de "bom".

        * De onde você tirou a idéia de que é tão valioso? Há seis bilhões de nós por aí. Você não é único. Como exatamente você se convenceu de que está tão alto na escala cósmica das coisas para ser tratado como igual pelos experts sem se importar em adquirir, você mesmo, conhecimento?"

Como geólogo, Dutch certamente tinha criacionistas em mente. Eu diria o mesmo para certos conspiracionistas que obviamente nunca assistiram uma aula de física na vida e se escoram na farta ignorância para tentar nos convencer que o homem nunca foi à Lua.

Método Ciêntífico

FURPS+

FURPS+ é um sistema para a classificação de requisitos, o acrônimo representa categorias que podem ser usadas na definição de requisitos, assim como representa atributos de Qualidade de Software, sendo ele parte do Rational Unified Process (RUP):

Functionality (Funcionalidade) – representa todo aspecto funcional do software, ou seja seus requisitos. É uma categoria com diversas subcategorias que variam de acordo com a aplicação. Sua medição considera, principalmente, o cumprimento dos requesitos especificados.

Usability (Usabilidade) – é o atributo que avalia a interface com o usuário. Possui diversas subcategorias, entre elas: prevenção de erros; estética e design; ajudas (Help) e documentação; consistência e padrões.

Reliability (Confiabilidade) – refere-se a integridade, conformidade e interoperabilidade do software. Os requisitos a serem considerados são: freqüência e gravidade de falha; possibilidade de recuperação; possibilidade de previsão; exatidão; tempo médio entre falhas (MTBF).

Performance (Desempenho) – avalia os requisitos de desempenho do software. Podendo usar como medida diversos aspectos, entre eles: tempo de resposta, consumo de memória, utilização da CPU, capacidade de carga e disponibilidade da aplicação.

Supportability (Suportabilidade) – os requisitos de suportabilidade agrupam várias características, como: testabilidade, adaptabilidade, manutenibilidade, compatibilidade, configurabilidade, instalabilidade, escalabilidade, localizabilidade entre outros.

O “+” do acrônimo engloba outros requisitos não-funcionais que devem ser lembrados:

    * Requisitos de design (desenho) – Um requisito de design, freqüentemente chamado de uma restrição de design, especifica ou restringe o design de um sistema. Exemplos podem incluir: linguagens de programação, processo de software, uso de ferramentas de desenvolvimento, biblioteca de classes, etc.
    * Requisitos de implementação – Um requisito de implementação especifica ou restringe o código ou a construção de um sistema. Como exemplos, podemos citar:
          o padrões obrigatórios;
          o linguagens de implementação;
          o políticas de integridade de banco de dados;
          o limites de recursos;
          o ambientes operacionais.

    * Requisitos de interface – especifica ou restringe as funcionalidades inerentes a interface do sistema com usuário.
    * Requisitos físicos – especifica uma limitação física pelo hardware utilizado, por exemplo: material, forma, tamanho ou peso. Podendo representar requisitos de hardware, como as configurações físicas de rede obrigatórias.

Enjoy!

Comportamentos de um Arquiteto

1. Ser franco. Ser honesto, dizer a verdade, usar linguagem simples, demonstrar integridade e não manipular pessoas estabelece conexões entre times e também com os envolvidos (clientes, patrocinadores, usuários e gerentes). Um projeto com pessoas desconectadas raramente irá cumprir seus objetivos. Um projeto com desenvolvedores versus usuários raramente resulta em relações ganha-ganha.

2. Demonstrar preocupação sincera. Um arquiteto deve ouvir e respeitar profundamente todo o time técnico. Ouvir requer tempo e disposição. Nào é possível e correto ser “eficiente” com o time de desenvolvimento, especialmente com iniciantes.

3. Criar Transparência. Um arquiteto não deve esconder informações do time. Ao invés, toda informação deve ser divulgada de forma aberta para críticas e melhorias.

4. Fazer dos Erros Acertos. Errar é humano. Reconhecer erros demonstra humildade. Pedir desculpas sinceras com rapidez demonstra grandeza.

5. Demonstrar Lealdade. É fundamental dar créditos às idéias de cada pessoa do seu time. Quando falar sobre qualquer pessoa do projeto (incluindo o cliente!), assuma que ele esteja presente.

6. Gerar Resultados. Um arquiteto deve produzir resultados consistentes durante todo o projeto. Manter o cronograma no prazo e gerenciar o orçamento técnico do projeto são aspectos chave para demonstrar competência técnica. Se algo fugir do planejado, o arquiteto não deve inventar desculpas pelo ocorrido.

7. Melhorar Continuamente. Aumentar permanentemente os conhecimentos técnicos e habilidades é uma obrigação. O arquiteto deve ser um aprendiz eterno. Para isso, ele deve desenvolvedor sistemas de feedback formais e informais e aprender com este sistema. Parar no tempo e assumir que você se tornou sênior é um erro mortal.

8. Encarar a Realidade. Enfrente a realidade e não as pessoas, i.e., trate as questões difíceis do seu projeto abertamente e não as esconda ou se esconda delas. Um bom arquiteto deve assumir os desafios e buscar soluções coletivas com todo o time para resolvê-las.

9. Esclareça as Expectativas. Abrir e revelar expectativas, discuti-las diariamente com o time e validá-las é chave para exercer liderança técnica. Se necessário, renegocie as expectativas. O arquiteto não deve violar as expectativas e nunca assumir que elas estejam claras ou compartilhadas antes que ele as discuta.

10. Pratique a responsabilidade. Seja responsável pelos resultados, positivos ou negativos. Não apontar os dedos para os outros em situaçòes da responsabilidade de um arquiteto é fundamental. Um arquiteto deve ser claro sobre como comunicar as suas ações no projeto e também as ações do time.

11. Ouvir primeiro. Ouvir é difícil. Ouvir atentamente é muito difícil. Entretanto, um arquiteto deve aprender a ouvir, entender e gerar diagnósticos. Interromper pessoas no meio de uma explicação técnica é sinal de menosprezo e desprezo. Ao invés, o arquiteto não deve assumir que ele tenha todas as respostas ou questões. Pratique o “ouvir” no seu projeto.

12. Honrar seus acordos. Diga o que você irá fazer. Então faça o que você disse que iria fazer. Mantenha os compromissos a qualquer custo, uma vez que você os tenha feito com o seu time. Se você marcou uma reunião, esteja lá pontualmente. Se disse que irá responder um email, responda-o. O compromisso é sinal de honra. A ausência do compromisso quebra a confiança.

13. Estender a Confiança. Demonstrar a propensão à confiança com as pessoas que você tenha ganho a confiança é fundamental. O arquiteto deve aprender como estender a confiança a outras pessoas baseado na situação, risco e credibilidade.

Enjoy!

Métodos Convencionais de Engenharia de Software

Há quase 500 anos, Machiavelli disse: "não há nada mais difícil de levar, mais perigoso de conduzir ou de sucesso incerto, do que tomar a liderança na introdução de uma nova ordem das coisas". Durante os últimos 50 anos, sistemas baseados em computador introduziram uma nova ordem. Apesar da tecnologia ter feito grandes avanços desde quando Machiavelli falou, suas palavras continuam a soar como verdadeiras.

Engenharia de Software ocorre como consequência de um processo chamado Engenharia de Sistemas. Em vez de se concentrar somente no software, a engenharia de sistemas focaliza diversos elementos, analisando, projetando e organizando esses elementos num sistema que pode ser um produto, um serviço ou uma tecnologia para transformação de informação ou controle.

O processo de engenharia de sistemas é chamado Engenharia de Processo de Negócio quando o contexto do trabalho focaliza uma empresa de negócios. Quando um produto (neste contexto, um produto inclui tudo de um telefone sem fio a um controle de tráfego aéreo) deve ser construído, o processo é chamado Engenharia de Produto.

Tanto a engenharia de processo de negócio, quanto a engenharia de produto tentam colocar ordem no desenvolvimento de sistemas baseados em computador.

Enjoy!

Provérbios sobre gerenciamento de Projetos

01 – Você não consegue produzir um bebê em um mês usando nove mulheres.

02 – O mesmo trabalho, sob as mesmas condições será estimado de forma diferente por 10 diferentes analistas ou por um mesmo analista em 10 diferentes vezes.

03 – A palavra mais útil e menos usada em gerenciamento de projetos é “NÃO”.

04 – Você pode convencer um idiota a assumir um prazo irreal, porém, você não pode obrigá-lo a cumpri-lo.

05 – O prazo mais ridículo é o mais caro e dificultoso de se cumprir.

06 – Quanto mais desesperada a situação, mais otimista ela o é.

07 – Poucas pessoas em um projeto conseguem resolver os problemas – porém muito mais pessoas criam problemas acima da capacidade das primeiras resolverem.

08 – Você pode congelar os requisitos de um sistema, porém não consegue congelar as expectativas.

09 – Congelamento de requisitos e o abominável homem das neves são parecidos – ambos são mitos e ambos se derretem quando calor apropriado é aplicado aos mesmos.

10 – As condições sob as quais uma promessa e feita são esquecidas, porém, a promessa será sempre lembrada.

11 – Aquilo que você não conhece o ferirá.

12 – Um usuário somente falará o que lhe for perguntado – nada mais.

13 – Diante de varias interpretações de um comunicado, a menos conveniente é a mais correta.

14 – O que não está escrito, não existe ou não foi dito.

15 – Parkinson e Murphy estão vivos e muito bem – no seu projeto.

16 – Quem não sabe aonde vai, nunca chega.

17 – Para quem está perdido, qualquer caminho serve.

18 – Para quem está perdido, um mapa não resolve.

19 – Noventa por cento do trabalho em um projeto, equivalem a 90% do planejado, os outros dez por cento, consomem os restantes 90% do trabalho.

20 – Prazo de sistemas e fidelidade são promessas difíceis de se cumprir.

21 – A única situação onde você tem tudo sob controle é quando você está morto.

22 – A demissão de um elemento da equipe, quase sempre é a preservação do emprego do resto.

23 – Depois que passei a estudar mais, trabalhar mais e planejar melhor, minha sorte mudou.

24 – Em projetos, não confunda folga nos prazos, com prazos dos folgados.

25 – Normalmente coisas ruins estão ligadas à palavra “usuário” – usuário de drogas, usuário de ônibus, usuário de álcool, usuário de sistemas. . .

26 – No caso de uma crise total no andamento de seu projeto – melhor do que a presença de espírito é a ausência de corpo.

27 – A logística de um projeto sempre exige àquilo que você esqueceu.

28 – Reunião sem pauta vira happy-hour.

29 – Reunião sem ata, não existiu.

30 – Para o usuário – o que você esqueceu sempre é o mais importante.

31 – Em projetos – quando um cachorro te morde, não é boa política correr e morder a perna do cachorro (porém, você pode sutilmente, colocar veneno na sua comida).

32 – O mérito por um projeto bem sucedido é como o funcionamento de um haras – A égua é um animal tão forte quanto o cavalo, e quando ela entra no cio, se torna violenta e trata o seu pretendente a coices e mordidas durante as preliminares sexuais. Como o cavalo puro-sangue é um animal muito valioso, o haras, para não machucá-lo, mantém um plantel de cavalos de baixa categoria (pangarés), chamados de rufiões e durante as preliminares sexuais, é sempre colocado um ou mais desses pangarés para exaurir a fêmea e esse animal (normalmente menor do que a égua) sofre o diabo nas patas e dentes da fêmea no cio, adicionalmente, esses pangarés têm uma cirurgia em seu pênis de forma a deixá-lo torto para evitar que acidentalmente consiga êxito. Quando a égua está exausta e receptiva ao macho, o pangaré babando é retirado e é substituído por um puro-sangue para a parte final do processo (óbvio a melhor parte). Em projetos de sistemas, sempre existe um plantel de pangarés que sofre todos percalços do projeto, isto é, todos coices e mordidas, e na hora da inauguração são substituídos, isto é, será chamado o puro-sangue de plantão para receber a melhor parte (promoção, prêmios, parabéns, elogios, etc.).

33 – Quando tudo estiver perdido – finja-se de morto. [pelo menos, por enquanto, as pessoas ainda respeitam os mortos (por um dia)].

34 – Equipe muito grande em projetos é como chinês fazendo túnel, eles colocam um buzilhão de chineses de um lado da montanha e outro buzilhão do outro lado. Se tudo der certo eles fazem um túnel, se der errado eles fazem dois.

35 – Equipe muito grande é como dinossauro, você tira um bife da ponta do rabo, até a dor chegar ao cérebro leva dois anos.

36 – Grupo de trabalho – quando você está dentro é equipe ou grupo de trabalho; quando você está fora é panela.

37 – Todo chefe tende a ser incompetente. (Peter, L.J.)

38 – Para tocar o seu projeto, conheça bem: o organograma, o mandograma, o orfacograma, o mafiograma, e fundamentalmente, o secretariograma.

39 – Se tudo aparentemente está andando bem, é porque você não olhou direito.

40 – A empresa só te paga para trabalhar, quando você fica nervoso isso é de graça.

41 – Todo membro incompetente da sua equipe é zelosamente pontual nos horários de entrada, almoço e saída. Porém, sua presença não agrega conteúdo, portanto, atrapalha a pontualidade dos prazos do projeto.

42 – A inteligência total do universo é constante, porém, continuam nascendo mais pessoas.

43 – A proporção de analfabetos de ontem com os de hoje, continua a mesma, porém, os analfabetos de hoje, sabem ler e escrever. (Moravia, A.)

44 – Nem se deita vinho novo em odres velhos; do contrário se rebentam, derrama-se o vinho, e os odres se perdem; mas deita-se vinho novo em odres novos, e assim ambos se conservam. (Bíblia, Matheus 17). Leitura sistêmica, não desperdice códigos novos em sistemas velhos e nem remonte sistemas velhos para ficarem novos.

45 – Quando seu chefe diz que vai colocar alguém para te ajudar, provavelmente você já foi demitido, é só uma questão de tempo.

46 – Quando o teu chefe pede para colocar no papel a sua brilhante idéia, é porque ele nunca vai vê-la.

47 – Reunião com mais de 2 horas, vira big brother.

48 – Não existe conflito quando a hierarquia é diferente.

49 – Quando um funcionário lhe procura para contar sobre uma idéia e você pede para que ele coloque no papel a sua idéia, essa atitude é a melhor maneira de bloquear a criatividade.

50 – Só erra quem esta inovando.

51 – O inferno não é tão ruim quando você é amigo do diabo.

52 – Qualquer que seja o seu projeto, ele nunca andará se a liderança estiver não mãos de um acadêmico, principalmente se o mesmo for doutor.

53 – A melhor maneira de um projeto não sair é designar uma equipe para decidir sobre a implementação do mesmo.

54 – Decisões são processos democráticos (toma-se em grupo), fazer é um processo ditatorial (deve ter um mandando). Adizes.

55 – Respeito aos membros da equipe alem de humano, protege os dentes.

56 – Respeito de forma geral protege os dentes.

57 – Membro canalha da equipe, é como cobra, só não te morde se estiver morto.

58 – “Bandido” em equipe de trabalho não é ser humano é doença oportunista.

59 – Os maus funcionários de uma equipe tendem a cada dia serem piores, pois todas noites de suas vidas eles são obrigados a dormir com um incompetente.

60 – Funcionária incompetente que sabe administrar a “piriquita” estraga a equipe e prejudica a empresa.

61 – Superior que transa com funcionária incompetente dando em troca favores profissionais, atingiu o nível mais baixo de inferioridade que o ser humano pode chegar.

62 – Ver um ser humano julgando a outro, é um espetáculo que me mataria de rir se não me causasse pena. Pitigrilli.

63 – Estola de peles é um animal que trocou de dono. Pitigrilli.

64 – Ninguém engole sapo pelo valor nutritivo do bicho. Veríssimo.

65 – Tirado de uma fonte é cópia, tirado de duas é plágio, porém, tirado de três é pesquisa.

66 – Não importa a qualidade de seu trabalho, a banca formada por acadêmicos só sabe ver a forma.

67 – Para ferrar o projeto da concorrência, indique um doutor para ajudá-los.

68 – Reconhecimento de chefe e coice de porco são parecidos, ambos são raros e quando ocorrem são curtos.

69 – Quando o gerente encontra a equipe feliz, ele fica infeliz, se perguntando onde foi que errou, não entendendo porque as pessoas estão contentes e rindo.

70 – Dize-me do que te gabas e direi o que te faltas. Freud.

71 – Em sistemas deve ser abolido o termo subentendido.

72 – As relações humanas contrariam as leis da física: quando efetivas, o somatório das partes é maior do que o todo; e quando falsas, o somatório do todo é menor do que as partes.

73 – O diabo tem dois nomes: esposa e gerente.

74 – Em projetos para calcular a parábola formada por uma pedra atirada a 30 metros, existem analistas que entrevistam a pedra.

Enjoy!

As várias formas várias formas de se dar uma notícia

Não sei qual a fonte, recebi no email :)

Se a história da Chapeuzinho Vermelho fosse verdade, como ela seria contada na imprensa no Brasil? Veja as diferentes maneiras de contar a mesma história.

Jornal Nacional

(William Bonner): ‘Boa noite. Uma menina chegou a ser devorada por um lobo na noite de ontem…’

(Fátima Bernardes): ‘…mas a atuação de um lenhador evitou a tragédia.’

Programa da Hebe

‘….que gracinha, gente! Vocês não vão acreditar, mas essa menina linda aqui foi retirada viva da barriga de um lobo, não é mesmo?’

Cidade Alerta

(Datena): ‘…onde é que a gente vai parar, cadê as autoridades? Cadê as autoridades? A menina ia pra casa da vovozinha a pé! Não tem transporte público! Não tem transporte público! E foi devorada viva… um lobo, um lobo safado. Põe na tela, primo! Porque eu falo mesmo, não tenho medo de lobo, não tenho medo de lobo, não!

Superpop

(Luciana Gimenez): ‘Geeente! Eu tô aqui com a ex-mulher do lenhador e ela diz que ele é alcoólatra, agressivo e que não paga pensão aos filhos há mais de um ano. Abafa o caso!’

Globo Repórter

(Chamada do programa): ‘Tara? Fetiche? Violência? O que leva alguém a comer, na mesma noite, uma idosa e uma adolescente? O Globo Repórter conversou com psicólogos, antropólogos e com amigos e parentes do Lobo, em busca da resposta. E uma revelação: casos semelhantes acontecem dentro dos próprios lares das vítimas, que silenciam por medo.. Hoje, no Globo Repórter.’

Discovery Channel

Vamos determinar se é possível uma pessoa ser engolida viva e sobreviver.

Revista Veja

Lula sabia das intenções do Lobo.

Revista Cláudia

Como chegar à casa da vovozinha sem se deixar enganar pelos lobos no caminho.

Revista Nova

Dez maneiras de levar um lobo à loucura na cama!

Revista Isto É

Gravações revelam que lobo foi assessor de político influente.

Revista Playboy

(Ensaio fotográfico do mês seguinte): ‘ Veja o que só o lobo viu’..

Revista Vip

As 100 mais sexies - desvendamos a adolescente mais gostosa do Brasil!

Revista G Magazine

(Ensaio com o lenhador) ‘O lenhador mostra o machado’.

Revista Caras

(Ensaio fotográfico com a Chapeuzinho na semana seguinte): Na banheira de hidromassagem, Chapeuzinho fala a CARAS: ‘Até ser devorada, eu não dava valor pra muitas coisas na vida. Hoje, sou outra pessoa.’

Revista Superinteressante

Lobo Mau: mito ou verdade?

Revista Tititi

Lenhador e Chapeuzinho flagrados em clima romântico em jantar no Rio.

Folha de São Paulo

Legenda da foto: ‘Chapeuzinho, à direita, aperta a mão de seu salvador’. Na matéria, box com um zoólogo explicando os hábitos alimentares dos lobos e um imenso infográfico mostrando como Chapeuzinho foi devorada e depois salva pelo lenhador.

O Estado de São Paulo

Lobo que devorou menina seria filiado ao PT.

O Globo

Petrobrás apóia ONG do lenhador ligado ao PT, que matou um lobo para salvar menor de idade carente.

O Dia

Lenhador desempregado tem dia de herói

Extra

Promoção do mês: junte 20 selos mais 19,90 e troque por uma capa vermelha igual a da Chapeuzinho!

Meia hora

Lenhador passou o rodo e mandou lobo pedófilo pro saco!

O Povo

Sangue e tragédia na casa da vovó.

Correio da Bahia e TV Bahia

Menina usando um chapeuzinho vermelho é atacada por um lobo e não consegue atendimento em nenhum hospital do Estado. Governador não se manifesta.

Enjoy!

Arquiteturas

Começamos nossa exploração com uma série de definições básicas e idéias nucleares. Segundo o historiador F.W.Janson (1991,p.84), os gregos antigos criaram a palavra arquitetura (archi/tektura): "Arquitetura siginificava alguma coisa mais alta do que a 'tektura' comum (isto é, 'construção' ou 'edifício')." [É] uma estrutura que se distingue do que é apenas prático, do tipo habitual pela sua escala, ordem, permanência ou solenidade de finalidade. Aprendemos com a arquitetura física que quatro fatores são essenciais a criação de projetos eficientes:

• Primado da Finalidade: o projeto final deve ter utilidade

• Adequação Arquitetônica: ter um estilo capaz de realizar a visão do arquiteto

• Uso de Materiais Estruturais Capazes de Implementar a Arquitetura: idem

• Disponibilidade de Tecnologias Colaterais Necessárias: lançar mão de saberes distintos, porém interligados

Será que conseguimos identificar esses fatores em nossas arquiteturas?

Enjoy!

Lidando com a complexidade

O ambiente de TI é complexo e vem se tornando cada vez mais complexo. O legado que não nos deixa, a heterogeneidade do ambiente com tecnologia dos mais variados fornecedores. Regras de domínio, também conhecida como "regras de negócio" cada vez mais sofisticadas e além de tudo isso, a sopa de letrinha da moda. Mas como separar o que é "core" do que é "support" dentro do ambiente? Algumas das experiências sempre apontam para o mesmo caminho: simplicidade. Mas o que é simplicidade? 

"Simplicidade ou frugalidade é a ausência de artifícios, extravagâncias e excessos de ordem material, social  ou psicológica."

Origem: Wikipédia, a enciclopédia livre.

Tal definição nos norteia. Vamos usá-la como estratégia para os mais variados assuntos, como:

• Gerenciamento de Projetos

• Bancos de Dados

• Redes de Computadores

• Servidores de Alta Disponibilidade

• Engenharia de Software

• Arquitetura de Software

• J2EE/J2SE/J2ME

• Pesquisa Operacional

• Modelagem de Processos de Negócios com BPM/BPMN

• Governança de TI com ITIL/COBIT

Enjoy!

Coisa bacana do fórum de UML. Como cobrar o preço do seu cliente:
Emmanuel

Funciona sim. Veja o que escrevi:

> Você vai lá, entende a idéia do software e usa um método
> de estimativa qualquer. Por exemplo, chutômetro. Seu
> objetivo não é fechar realmente preço e prazo, mas
> entender qual preço e qual prazo são aceitáveis para seu
> cliente.

Ou seja, um entendimento macro do sistema e do esforço. Se vc não
conhece o negócio, aumente o fator de risco.

> A adoção da abordagem iterativa do tipo "time boxed"
> determina que uma vez estipulados prazo e preço, esses
> itens tornam-se imutáveis.

Isso responde à sua pergunta: O PROJETO TEM UM PREÇO FINAL e é o
primeiro preço que vc passou, no passo anterior.

Você perguntou:
>> meio do caminho cara vai te explicar que para
>> determinado processo ele faz um monte de coisas que você
>> não tinha previsto. Mas aí como você fechou um
>> valor com o cara...

Não tem problema. Você fechou um valor e um prazo. Vejamos o que eu
disse na msg anterior a esse respeito:

> Durante as iterações, você trabalhará com escopo
> deslizante. Haverá uma lista de funcionalidades,
> priorizadas pelo cliente. Em cada iteração, serão
> implementadas tantas funcionalidades quanto a equipe
> de desenvolvimento conseguir.
>
> Ao final de cada iteração, o cliente avaliará o resultado
> e dirá as mudanças que quer.
>
> A equipe avaliará as mudanças e dirá quanto "custam"
> em termos de *TEMPO*. O cliente deverá então eleger as
> funcionalidades da lista original irão "morrer" para dar
> lugar às mudanças solicitadas. E assim por diante.
>
> A premissa é que até 40% das funcionalidades de um
> sistema nunca são usadas. Esses 40% é que morrem durante
> as iterações.
>
> No final, o cliente tem um sistema menor do que o pensado
> originalmente, mas que atende plenamente suas necessidades,
> dentro do prazo e dentro do orçamento.

Entendeu?

O segredo está em combinar a regra do jogo com o cliente. Funciona.

[]s

MT.

package roseindia.tutorial.hibernate;

import java.util.Iterator;
import java.util.List;

import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;

public class HibernateHQLMaxFunction {

/**
* evertongomede@gmail.com
*/
public static void main(String[] args) {
// TODO Auto-generated method stub

Session sess = null;
try {
SessionFactory fact = new Configuration().configure().buildSessionFactory();
sess = fact.openSession();
String SQL_QUERY = "select max(c.id)from Cliente c";
Query query = sess.createQuery(SQL_QUERY);
List list = query.list();
System.out.println("Max : " + list.get(0));
sess.close();
}
catch(Exception e){
System.out.println(e.getMessage());
}
}
}

Mais uma coisa legal do grupo de UML

"É muito comum o pessoal classificar como retrabalho alguns refinamentos comuns. É interessante ressaltar que a maneira como um software é produzido necessita de um processo empírico por ser de natureza criativa. Antes de prosseguir, precisa estar claro que o desenvolvimento de software é uma atividade criativa, se vcs não concordam podemos discutir aqui.

Determinados processos são prescritivos, isto é, possuem pontos observáveis que a cada passo podem ser verificáveis como válidos. A construção de uma ponte segue um processo prescritivo. Uma linha de montagem de um produto é um processo prescritivo. A forma que um cartório funciona é um processo prescritivo. Uma característica importante dos processos prescritivos é que se caso o produto final não atenda o nível de qualidade que você espera o custo é muito alto para reconstruir esse produto novamente ou para reparar a falha. Como exemplo, se um carro ao final da linha de produção foi montado de maneira errada é praticamente impossível recolocá-lo na linha para que seja produzido da maneira certa. É mais barato jogar o carro no lixo e corrigir a linha de produção.

O software não possui passos intermediários que possam ser verificáveis como válidos. Quando você captura requisitos você não tem certeza que eles solucionarão o negócio, quando você elege uma arquitetura não tem certeza se ela será suficiente, quando você codifica soma-se a essas incertezas aspectos técnicos e também com relação ao futuro. Nós só conseguimos reduzir essa incerteza quando o usuário olha a aplicação. Por conta disso, chegamos à declaração abaixo:

DESENVOLVIMENTO DE SOFTWARE = GERENCIAMENTO DE INCERTEZA

Com relação a retrabalhos, imagine que você capturou requisitos com relação a tela de pedidos e com a entidade de pedidos. Você modelou e implementou de acordo com o que você definiu como objetivos da sua iteração. Você mostra a tela para o usuário, ele gostou do que viu, mas ainda falta algumas coisas que podem fazer parte da próxima iteração. O fato de você ter que mexer na tela novamente ou na entidade não significa
necessariamente retrabalho e sim refinamentos. O que mostra o andamento do projeto é o cumprimento desses objetivos e não o número de telas implementadas. Se depois, na 20 iteração, algum conceito de negócio necessite de mais ajustes na entidade pedido também não será retrabalho, simplesmente é o software amadurecendo. Não considero ter que mexer em coisas já implementadas como retrabalho, principalmente se o processo é
ágil. Nós trabalhamos dessa maneira porque o PRODUTO SOFTWARE nos permite que o tratemos dessa forma. O custo para ajustar os conceitos no SOFTWARE não segue o padrão de um produto de processo prescritivo. A tecnologia nos permite construir o software dessa maneira. Isso nos leva a outro conceito:

SOFTWARE = IDÉIA

Idéias são coisas que amadurecem. É bem raro uma maçã cair na sua cabeça e de uma hora para outra você ter a idéia completa de como resolver com um software o caos aéreo no Brasil. O software assim como uma campanha publicitária, ou uma ação de marketing, ou um novo produto, é algo que floresce com a participação de muitas pessoas e chega a maturidade em constante inspeção e adaptação."

RODRIGO YOSHIMA