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

Um grupo de cientistas colocou cinco macacos numa
jaula. No meio, uma escada e sobre ela um cacho de
bananas. Quando um macaco subia na escada para pegar
as bananas, jogavam um jato de água fria nos que
estavam no chão. Depois de certo tempo, quando um
macaco ia subir a escada os outros o pegavam e enchiam
de pancada. Com mais algum tempo, nenhum macaco subia
mais a escada, apesar da tentação das bananas.

Então substituíram um dos macacos por um novo.

A primeira coisa que ele fez foi subir a escada, dela
sendo retirado pelos outros, que o surraram.
Depois de algumas surras, o novo integrante do grupo
não subia mais a escada. Um segundo foi substituído
e o mesmo ocorreu, tendo o primeiro substituto
participado com entusiasmo na surra ao novato.
Um terceiro foi trocado e o mesmo ocorreu. Um quarto
e afinal o ultimo dos veteranos foi substituído.

Os cientistas então ficaram com um grupo de cinco
macacos que mesmo nunca tendo tomado um banho frio,
continuavam batendo naquele que tentasse pegar as
bananas. Se possível fosse perguntar a algum deles
porque eles batiam em quem tentasse subir a escada,
com certeza a resposta seria:

"Não sei, mas as coisas sempre foram assim por aqui".

(fonte: João Barcellos)

Outra coisa bacana do fórum de UML:

"Amigos(as),

Pergunta da sexta-feira para discussão e reflexão.

Muito se fala hoje sobre processo prescritivo x processo empírico.
Pessoalmente tenho tido algumas experiências positivas em dar maior
liberdade para a equipe criar soluções com pouca intervenção ou
imposição de autoridade.

Com tudo isso, levo umas dúvidas para discussão. Na opinião do grupo,
qual o valor de se ter um processo descrito "todo bonitinho" com guias
de trabalho, modelos, templates, papéis, fluxos de trabalho? Qual o
nível de liberdade que podemos dar à equipe sobre o processo? O
processo perde valor se determinado projeto não tem aderência mínima?

O que vale mais: uma equipe culta em boas práticas ou um processo
detalhadamente descrito? É trabalho do processo ensinar a equipe?

Abraços e bom final de semana!

Rodrigo Yoshima
ASPERCOM"

O Processo de Desenvolvimento de Software

Um processo de desenvolvimento de software

• Uma linguagem de modelagem não é suficiente
• Precisamos também de um processo de desenvolvimento
  • Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento
• O que é um processo de desenvolvimento?
  • Define quem faz o que, quando e como, para atingir um certo alvo
• Veremos os detalhes de processos concretos em outras disciplinas
  • Aqui, só uma introdução
• As grandes fases de qualquer processo de desenvolvimento
  • Planejamento e elaboração
    • Planejamento, definição de requisitos, construção de protótipos (opcional)
  • Construção do sistema (inclui codificação e testes)
  • Implantação (colocar em produção, treinar usuários, ...)

A Fase de Planejamento e Elaboração

1. Criar relatório inicial de investigação (para construir o business case)
2. Levantar requisitos funcionais e não funcionais
3. Construir glossário (ao longo da fase)
4. Definir modelo conceitual inicial (análise inicial)
5. Projetar arquitetura
6. Priorizar a funcionalidade e distribuí-la entre as iterações

Detalhes sobre o levantamento de requisitos

• Requisitos são "cortes" no espaço de solução
• Entendimento do que o usuário quer
• O resultado é uma promessa para o cliente
• Não só requisitos funcionais, mas também:
  • Facilidade de uso necessária
  • Quem utilizará o produto
  • Hardware e software alvo para o produto
  • Qualidade/robustez
  • Desempenho
  • Segurança
  • Compatibilidade com outros produtos/versões e necessidades de migração
  • Necessidades de internacionalização do produto
  • Suporte
  • Preço da solução
  • Documentação necessária
  • Uso de padrões
  • Aspectos legais
  • Integração com outros produtos
  • Packaging
  • etc.
• Não se fala "como" as coisas serão feitas
• "Use cases" descrevem cenários de funcionalidade desejada
  • Também chamados de "User Stories", pois é o usuário que decide o que deve ser feito

Detalhes sobre a fase de Construção

• Hoje, é considerado errado ter um processo que gere um "big bang!"
  • Não se deve ter o software inteiro funcionando por inteiro no primeiro release
  • O risco é grande demais!
• Um processo de desenvolvimento deve ser:
  • Iterativo (ter várias iterações no tempo)
  • Incremental (gerar novas versões incrementadas a cada release)
  • Uma iteração dura entre 2 semanas e 2 meses
• Motivos:
  • Sempre tem algo para entregar para o cliente apressado (a última iteração)
  • Os requisitos mudam com tempo e um processo iterativo mantém freqüentes contatos com o cliente o que ajuda a manter os requisitos sincronizados
  • Altamente motivador para a equipe de desenvolvimento (e o cliente) ver o software funcionando cedo
  • Para evitar isso:

• O que é feito a cada iteração?
  • Análise (refinamento de requisitos, refinamento do modelo conceitual)
  • Projeto (refinamento do projeto arquitetural, projeto de baixo nível)
  • Implementação (codificação e testes)
  • Transição para produto (documentação, instalação, ...)

Detalhes sobre a análise

• A análise gera um modelo para entender o domínio do problema
• Análise também trata em alto nível de como uma solução possível pode ser montada para atender aos requisitos
  • Acaba gerando uma especificação, mas sempre do ponto de vista do usuário e tratando apenas do domínio do problema
• Não trata de detalhes de implementação
• Objetos tratados são sempre do domínio do problema (business objects)
• Muitos diagramas UML podem ser usados
  • O modelo é para o cliente e não para o programador
• Atividades típicas durante a análise

1. Refinar use cases
2. Refinar modelo conceitual
3. Refinar glossário
4. Definir diagramas de seqüência (opcional)
5. Definir contratos de operação (opcional)
6. Definir diagramas de estado (opcional)

Detalhes sobre o projeto (design)

• O projeto é uma extensão do modelo de análise visando sua implementação num computador
• Novos objetos aparecem, mas não são do domínio do problema
• O resultado é para o programador ver, não o cliente
• Objetos da análise são (geralmente) mantidos e são embutidos numa infra-estrutura técnica
  • As classes técnicas ajudam os business objects a:
    • Serem persistentes
    • Se comunicarem
    • Se apresentarem na interface do usuário
    • Terem desempenho aceitável (usando caches ou threads, por exemplo)
• As atividades de projeto incluem:
  • Fase de refinamento da arquitetura (high-level design)
    • Definição de pacotes (módulos), interfaces entre pacotes
    • Decisão sobre uso/criação de bibliotecas e/ou componentes
    • Falaremos disso em detalhes adiante
  • Fase de projeto detalhado (low-level design)
    • Atribuição de responsabilidades entre os objetos
    • Construção de diagramas de classes
      • Pode incluir documentação javadoc (ideal)
    • Construção de diagramas de interação (opcional)
    • Levantamento de necessidades de concorrência
    • Considerações de tratamento de falhas
    • Detalhamento do formato de saída (interface com usuário, relatórios, transações enviadas para outros sistemas, ...)
    • Definição do esquema do BD
    • Mapeamento de objetos para tabelas se o BD for relacional
  • Advertência: se você usar Test-Driven Development, então o design é feito bolando testes e escrevendo o software ao mesmo tempo
    • Neste caso, fazer diagramas ou Javadoc antes de codificar não funciona

Detalhes sobre a implementação

• Escrita do código
• Relativamente simples se o projeto tiver sido bem feito
• Programadores devem normalmente seguir regras de codificação da empresa
• Atividades incluem code reviews
• Não se deve chegar a esta fase cedo demais!
  • Mais cedo você agarra o teclado, mais vai demorar a terminar!
• Poucos novos diagramas nesta fase

Detalhes sobre os testes

• Inclui várias fases de testes
• Testes feitos pelo próprio programador durante a programação
  • Unit test: teste de classes individuais (ou de grupos de classes relacionadas)
  • Functional test: teste de funções inteiras (item de menu, p. ex.)
  • Component test: teste de componentes inteiros (exe, dll, ...) sem (ou com pouco) scaffolding
• Testes feitos por equipes independentes de teste
  • System test: testa a integração entre todos os componentes do produto
  • Alpha test: teste de produto inteiro dentro de casa
  • Beta test: teste de produto inteiro fora de casa
• Testes devem ser automatizados

Outra coisa bacana a respeito de casos de uso que li no forum de UML. Segue o post na integra.

"Assino em baixo da resposta do nosso amigo MT...

Outra coisa importante (e que discutimos na minha aula de ontem) é que não é só na "fase" de levantamento que todos os requisitos são descobertos, ou melhor, não é só da equipe de requisitos a responsabilidade por todos os requisitos. Por exemplo, veja a narrativa a seguir:

Caso de Uso: Consultar Pedido - Versão: 1.2

Ator: Vendedor

1. O Ator inicia o caso de uso selecionando "Consultar Pedido";
2. O Sistema oferece a interface de consulta para pedidos;
3. O Ator informa o número do pedido desejado [A1];
4. O Sistema exibe os dados do pedido [A2];
Fluxo Alternativo A1 ? Consultar por Cliente
3. O Ator informa um cliente;
3.1. O Sistema exibe uma lista de pedidos do cliente selecionado em ordem cronológica decrescente;
3.2. O Ator seleciona um pedido do cliente; volta ao fluxo básico;


No passo 3 do fluxo básico, se o ator informar um número de pedido que não existe, o sistema deverá mostrar uma mensagem "Pedido Inexistente". Porém, esse tipo de "anomalia" não precisa estar necessariamente no caso de uso. Costumo dizer que esse requisito fica por responsabilidade do seu "caprichoso" programador.Algumas pessoas questionam sobre o teste desse "pedido inexistente". Mais
uma vez, não fica a cargo de quem escreveu o caso de uso captar todas as possibilidades e validações para que o teste seja 100%. Se o caso de uso sempre tiver que ter todos os requisitos, todos eles teriam mais de 20 páginas. O teste desse "pedido inexistente" também fica a cargo do seu "atencioso" tester. Um bom tester capta esse tipo de erro.Toda a equipe é responsável pelos requisitos. Os requisitos do caso de uso
são aqueles importantes para o negócio. Se algum desenvolvedor não for "caprichoso" e alguma vez falar "Não está no caso de uso então não vou implementar!", mande ele embora. A mesma coisa vale para o tester.
Valeu?!?!


Rodrigo Yoshima
ASPERCOM
Curso UML e Requisitos em São Paulo
www.aspercom.com."