Aprenda Programar em Dez Anos

Este pequeno texto é uma adaptação do artigo "Teach Yourself Programming in Ten Years" de Peter Norvig, que pode ser lido integralmente em http://norvig.com/21-days.html.

Não é difícil encontrar livros com títulos tais como: "Aprenda Java em 7 Dias", "Aprenda Pascal em Três Dias", e assim por diante. A primeira impressão que se tem é que há uma grande corrida para aprender computação, ou que computação é algo muito mais fácil de aprender que qualquer outra coisa. Ou alguém já viu livros sobre como aprender tocar piano, física quântica ou adestrar cães em tão poucos dias?
Pesquisadores têm mostrado que leva-se aproximadamente dez anos para tornar-se um expert em uma grande variedade de áreas que incluem: jogar xadrez, compor músicas, pintar, nadar, jogar tênis, etc. Mozart, considerado um prodígio musical aos 4 anos, levou mais 13 anos antes de começar a produzir música de qualidade. O grupo musical The Beatles surgiu com um sucesso em primeiro lugar nas paradas em 1964, mas já vinham tocando desde 1957. Samuel Johnson acredita que pode levar mais que dez anos: "Excelência em qualquer área pode ser alcançada apenas com esforço de uma vida toda; não dá para ser comprada por menos que isso".

Peter Norvig dá sua receita para obter sucesso em programação:

• Se interesse por programação, e faça por que é divertido. Tenha certeza que é dvertido para você dedicar dez anos nisso.
• Programe. A melhor forma de aprender é "aprender fazendo".
• Você pode passar quatro anos em uma universidade. Mas lembre-se "Educação em ciência da computação não faz de ninguém um gênio em programação tanto quanto estudar pincéis e pigmentos não fazem um bom pintor" segundo Eric Raymond.
• Trabalhe em projetos com outros programadores. Aprenda com eles e teste suas habilidades.
• Procure entender programas escritos por outros. Desenvolva programas que sejam fáceis de manter por outros programadores.
• Aprenda pelo menos meia dúzia de linguagens de programação. Preferencialmente de paradigmas diferentes: orientadas a objeto, funcionais, de script, estruturadas, etc.
• Lembre que existe um computador onde seu programa irá rodar. Saiba quanto tempo leva para o seu computador executar uma instrução, carregar uma palavra na memória, ler palavras do HD, etc.
• Se envolva no esforço de padronização de uma linguagem.
• Tenha o bom senso de cair fora desse processo de padronização tão rápido quanto possível.

Por tudo isso, é duvidoso o quão longe você pode ir apenas lendo livros. Norvig conclui que muitas pessoas já possuem as qualidades necessárias para serem grandes programadores, o grande trabalho consiste em colocá-las no caminho certo.

Convenções de código

Convenções de código são um padrão de codificação que um grupo de programadores decide seguir. Isso inclui nomes de variáveis, de arquivos, identação, comentários, etc. Segundo o site da Sun, as convenções de código são importantes para os programadores por três razões:

• 80% do custo de desenvolvimento de um software é gasto com manutenção
• Dificilmente um software é mantido por toda sua vida pelo autor original
• Convenções de código dão legibilidade ao software

Nas aulas de Linguagem de Programação Comercial eu procuro mostrar ao alunos a importância de usar convenções de código até mesmo em benefício do seu próprio aprendizado. Utilizamos Delphi nessa disciplina e vou documentar aqui o padrão que eu criei no desenvolvimento de meus sistemas e o qual eu os aconselho a utilizarem.
No caso dos componentes eu os nomeio iniciando com duas ou três letras minúsculas abreviando o tipo do componente seguidas de um nome iniciando em maiúscula:

• Botões (TButton, TBitBtn, TSpeedButton) - iniciam com btn. Exemplo: btnFechar, btnOk, btnCancelar
• Caixas de texto (TEdit) - iniciam com edt. Exemplo: edNome, edEndereco
• Caixas combinadas (TComboBox) - iniciam com cbx. Exemplo: cbxCidade, cbxEstado
• Caixas de lista (TListBox) - iniciam com lb. Exemplo: lbProfissao, lbEscolaridade
• Rótulos (TLabel) - iniciam com lbl. Exemplo: lblNome, lblEndereco
• Barra de rolagem (TScrollBar) - iniciam com sb. Exemplo: sbIdade
• Caixas de verificação (TCheckBox) - iniciam com chx. Exemplo: chxSituacao
• Menus (TMainMenu, TPopUpMenu) - iniciam com mn. Exemplo: mnPrincipal
• Formulários (TForm) - iniciam com frm. Exemplo: frmPrincipal
• Unidades (Unit) - iniciam com u_. Exemplo: u_principal
• Tabelas (TTable) - iniciam com tb. Exemplo: tbProduto, tbCliente.
• Fontes de dados (TDataSource) - iniciam com ds. Exemplo: dsProduto, dsCliente.
• Queries (TQuery) - iniciam com que. Exemplo: queProduto, queCliente.
  

Além disso procuro identar o código e usar nomes que sugiram a função (a que se destina) de cada variável ou componente.

Minha paixão pela computação - IV

Quando eu iniciei meus estudos sobre Cobol, a empresa onde eu trabalhava tinha uma ferramenta CASE que gerava código COBOL a partir da definição da estrutura de uma tabela. Eu definia como eu queria a tabela e a ferramenta gerava o código completo de um módulo de cadastro. Assim eu comecei a analisar esse código, ler alguns livros e daí surgiram minhas primeiras aventuras nessa linguagem. Nessa época, 1986, a www ainda não existia. O primeiro navegador, Mosaic 1.0, só foi lançado em 1993. Os programas em COBOL que eu criava rodavam nos MAGNEX que falei antes. Eram computadores multiusuário. Logo surgiram os compatíveis com IBM-PC e a MAGNEX simplesmente quebrou, faliu. Os primeiros IBM-PC eram baseados no processador 8088 da Intel e rodavam apenas o sistema operacional MS-DOS, que não oferecia recursos multiusuário e redes eram um conceito que estava nascendo. Passamos por um momento de indefinição. Precisávamos de solução multiusuário e os compatíveis IBM-PC não suportavam esse recurso. Saímos atrás de alguma coisa que nos desse uma esperança e encontramos o sistema operacional PICK. PICK é multiusuário, suporta memória virtual, tempo-compartilhado, banco de dados e linguagem de programação integrados e, pasmem, a gente podia pendurar dois terminais burros em um PC-XT. PC-XT era um IBM-PC com 640Kbytes de memória RAM, 4.77 MHz de clock e disco rígido de 10 ou 20 Mbytes. Logo viagei a São Paulo onde fiz um curso de PICK Básico e Avançado me credenciando a desenvolver software nessa plataforma. Fizemos um programa que acompanhava a apuração das eleições, que era manual, nessa plataforma. O grande problema desse sistema operacional era a falta de compatibilidade com o sistema de arquivos do MS-DOS. No início dos anos 90 comecei a estudar CLIPPER. Em 1991 iniciei uma nova fase na minha vida profissional, passei a trabalhador autônomo. Durante cerca de 10 anos a linguagem CLIPPER foi minha fonte de renda. Ainda hoje tenho clientes que utilizam programas meus escritos em CLIPPER. Em julho de 1996 fui mais uma vez a São Paulo, desta vez fazer um curso de DELPHI. Em agosto de 1996 fui admitido como professor no Instituto Luterano de Ensino Superior. Uma nova fase se inicia, que eu começo a contar no próximo post.

Minha paixão pela computação - III

Após concluir o curso de Engenharia vim para Santarém. Alguns sintomas do vírus começaram a se manifestar e eu senti a necessidade de comprar um microcomputador. Uma empresa de Belém ofereceu um curso de programação em linguagem BASIC na cidade e junto trouxe alguns micros para vender. BASIC é uma linguagem criada para fins didáticos. Muitos microcomputadores, inclusive o IBM-PC, saiam de fábrica com BASIC embutido em uma memória ROM. O Visual Basic é um dos descendentes mais conhecidos do BASIC. Bem, entre os micros oferecidos pela empresa, o que eu podia comprar era o TK-85. TK-85 era um micro com 16 Kbytes de memória RAM, que era ligado a um aparelho de TV, que servia de monitor, e para armazenar os programas e dados utilizava-se um gravador de fita cassete. As imagens eram em preto e branco. Tudo muito estranho para os nerds atuais, mas para um nerd da década de 80 era o máximo. Dava para aprender a programar em BASIC e fazer muitas experiências. Ah! Eu me divertia mesmo era programando em assembly, sempre gostei muito de programação em baixo nível. Consegui então um jogo de xadrez para rodar nele. Não havia suporte gráfico nesse micro. As peças do jogo de xadrez eram representadas pelas letras iniciais: peão era P, rei era K, e assim ia. Nos jogos de xadrez quando se aumenta o nível do jogo, o computador gasta mais tempo "pensando" em que jogada fazer. No TK-85, a partir de determinado nível, ele apagava a tela para poder ter mais recurso de CPU para "pensar". Pensem na minha angústia, imaginando se ele ainda ia voltar desse apagão. Depois eu vendi o TK-85 e um terreno para comprar um CP-400. Eu já fui mais louco que sou hoje. O CP-400 tinha 64 Kbytes de memória RAM e suportava cores, gravador de fita cassete e disquetes de 5"1/4. Esse eu não tive oportunidade de programar, mas rodava BASIC também. No início de 1986 comecei a trabalhar na primeira empresa de informática de Santarém. Mas, devido minha formação em eletrônica, iniciei no setor de manutenção. Nesse mesmo ano fui a São Paulo fazer treinamentos. Passei uma semana na Prológica e uma semana na Magnex Eletrônica. É bom dizer que nessa época vigorava a reserva de mercado no Brasil, ou seja, não era possível importar, tudo era fabricado aqui. Então os fabricantes nacionais pegavam um micro importado, estudavam a coisa e faziam clones, nada perfeitos, mas eram clones. Hoje os fabricantes nacionais importam todas as peças, montam o micro e botam sua marca nele. Bem, voltei para Santarém. A empresa vendia dois modelos de computador, o CP-500 da Prológica, e outro da Magnex, que não recordo o nome. O CP-500 era um desses clones, assim como o TK-85 e o CP-400. Tinha 48 Kbytes de memória RAM, monitor de fósforo verde, e dois drives de disquete de 5"1/4 com capacidade de 178 Kbytes cada um. Rodava os sistemas sistemas operacionais DOS 500 e SO08, compatível com o CP/M. No CP/M dava pra executar um editor de textos chamado WordStar e um banco de dados chamado Dbase II. O computador da Magnex era multiusuário, aceitava terminais burros e usava HDs, sendo que os primeiros que instalamos tinham capacidade de 5 Mbytes e rodava CP/M. Poucos empresários apostavam nos computadores, então a empresa tinha poucos clientes. Sobrava tempo para eu me aventurar em outras atividades. Comecei a estudar a linguagem COBOL, muito usada naquela época para desenvolver aplicações comerciais. Mas essa parte da história será detalhada no próximo post.

Tecnologia Java Card

Java Card é uma plataforma da tecnologia Java da Sun Microsystems que possibilita que smart cards e outros dispositivos com memória muito limitada executem applets. Essa tecnologia oferece aos fabricantes uma plataforma interoperável e segura, que pode armazenar e atualizar múltiplas aplicações em um único dispositivo. A tecnologia permite que desenvolvedores criem, testem e distribuam aplicações e serviços com rapidez e segurança. A Sun, da mesma maneira que procede para outras tecnologias Java, também disponibiliza uma especificação da plataforma e um kit de desenvolvimento Java Card.
Suas principais características são:

• Interoperabilidade. Escreva uma vez e rode em qualquer cartão que suporte Java Card.
• Seguro. Além da segurança herdada de J2SE, implementa funções de criptografia.
• É Java.
• Múltiplos aplicativos num mesmo cartão. Num mesmo cartão você pode ter serviços de banco, telefone, vale-refeição, etc.
• Dinâmico. É possível instalar um novo applet mesmo que o cartão já tenho sido distribuído. A atualização pode ser feita na próxima vez que o cartão for inserido no terminal.
• Compatibilidade com padrões existentes para smart cards.

Praticamente qualquer tipo de smart card pode se beneficiar da tecnologia Java Card:

• Cartões Subscriber Identity Module (SIM), usados em telefones celulares. Esses cartões servem para identificação dos usuários. Com Java Card podem oferecer serviços bancários, por exemplo.
• Cartões para transações financeiras online e offline. O sistema com essa tecnologia pode permitir inclusive transações offline. Se você precisar fazer um saque e não estiver próximo de um terminal a transação pode ser realizada. Na próxima vez que você se conectar os dados são sincronizados.
• Cartões de identificação de planos de saúde que podem carregar o prontuário de seus usuários.

Os desenvolvedores dispõem de todas as vantagens de trabalhar com a linguagem Java:

• Programação orientada a objetos.
• Característica de proteção da linguagem aplicada aos applets Java Card e
• Disponibilidade de poderosas ferramentas de desenvolvimento.

Minha paixão pela computação - II

Depois de terminada "Introdução à Computação", bastante motivado, matriculei-me em "Estruturas da Informação". O conteúdo dessa disciplina é o mesmo de Estruturas de Dados I: listas, filas, pilhas, etc. Foi um desastre. Não consegui acompanhar e abandonei na metade do semestre. Minha única reprovação na graduação. Inesquecível e frustrante. Alguns semestres depois, chegou na universidade um novo brinquedinho, o DECSystem/10 da Digital. O DEC-10, como era comumente chamado, tinha 256k palavras de 36 bits de memória e também era chamado PDP-10. Leia mais sobre ele em http://en.wikipedia.org/wiki/PDP-10. Que avanço! Terminais de vídeo nos setores administrativos, na pesquisa, no Departamento de Engenharia Elétrica (DEE), em suma: uma maravilha. O curso de Tecnologia em Processamento de Dados ofereceu então um curso de extensão de férias sobre a nova versão do FORTRAN que rodava no DEC-10. O DEC10 rodava FORTRAN IV e V, COBOL, LISP, PROLOG, ALGOL, entre outras linguagens ilustres desconhecidas. A parte prática do curso ainda acontecia da mesma forma que se procedia no IBM 1130. Ainda era necessário produzir cartões perfurados para o código, mas, pasmem, o resultado do programa saía em duas horas. O curso de extensão me abriu a mente para a programção e eu pude, enfim, cursar com tranquilidade "Estruturas da Informação" e "Técnicas de Programação", as outras das três únicas disciplinas ligadas à computação do curso de Engenharia Elétrica. Eu ainda não sabia, mas já eu já havia contraído o vírus que iria se manifestar anos mais tarde.
No DEE, nesse período, estava sendo construído, como produto de trabalhos de conclusão de curso (TCC), um microcomputador baseado no microprocessador 8080 da Intel. O 8080 era um processador de 8 bits, precursor do 8088, que originou o IBM-PC, ancestral dos atuais Core 2 Duo, Dual Core, etc. Esse microcomputador já estava funcionando, sendo operado através de um painel de chaves. Veja uma imagem desse painel aqui. Podia apenas ser programado em binário. Cada instrução assembly deveria ser convertida para binário e introduzida na memória através das chaves. Cada chave ligada correspondia ao bit 1 e desligada ao bit 0. O resultado do programa era mostrado através de um conjunto de LEDs (Diodo Emissor de Luz). Tudo muito simples e prático. Um bit errado e se começava tudo de novo. Coisa de paixão mesmo. Algo bem primitivo, mas um laboratório fantástico.
Veio então o meu maior desafio na graduação: construir um programa em assembly que permitisse a carga de programas através de um teclado e que o reultado fosse mostrado em um monitor de vídeo. As instruções do programa a ser carregado estariam em hexadecimal. Convenhamos, um pouco melhor que binário. Esse foi o meu TCC. O trabalho foi feito. Relendo-o agora eu penso que seu fosse o meu orientador eu não iria para a defesa. No entanto não tive a chance de testar o programa. O terminal de vídeo que deveria ser utilizado não chegou a tempo para a realização dos testes antes da defesa. Para alívio meu. Não sei até hoje se a coisa funcionou. Meu TCC foi todo produzido usando uma máquina de escrever manual e as figuras desenhadas à mão usando uma caneta preta e régua. Quanta mão de obra.
Enfim, em Dezembro de 1980 encerrei o curso de Engenharia Elétrica e voltei para Santarém. Mas essa parte eu começo a contar em um outro dia.

Múltiplas habilidades

Até o ano de 2005 a principal linguagem de programação estudada no curso de Sistemas de Informação do Centro Universitário Luterano de Santarém era Pascal. Além de Pascal, alguns outros paradigmas eram estudados brevemente na disciplina Paradigmas de Linguagens de Programação, e C++ um pouco mais profundamente abordado em linguagem de Programação Orientada a Objetos. Há muito vinha sendo discutido nas reuniões do colegiado a inclusão de Java como a principal linguagem do curso. Sempre se colocava em pauta a dificuldade que os alunos teriam com o novo paradigma como um obstáculo à concretização da idéia. Observa-se que aos alunos serem apresentados a um paradigma, eles se fecham para todos os outros. Essas dificuldades eram sentidas quando se iniciava o estudo de C++. Enfim, a partir do ano de 2006, Java foi implantada como linguagem a ser estudada nas disciplinas iniciais do curso. Um excelente trabalho foi realizado como forma de disseminar a linguagem entre os membros da comunidade acadêmica do curso, principalmente com a criação do projeto de extensão Java & Eu. O que se constata agora é a resistência oferecida pelos acadêmicos ao serem apresentados a uma nova linguagem para eles, principalmente Pascal. A seguir serão apresentados argumentos que justificam o estudo de Pascal, além de Java, no curso de Sistemas de Informação.
O curso de Sistemas de Informação tem como objetivo formar profissionais que estejam aptos a avaliar, dimensionar e selecionar recursos de tecnologia da informação de acordo com as necessidades específicas de uma organização. Esta é apenas uma das habilidades que deve ter o egresso do curso, além de outras. Assim, o curso deve prover aos acadêmicos diversas abordagens sobre uma mesma matéria de forma que eles estejam preparados para oferecer opções diferenciadas às empresas onde venham prestar serviço. Em conseqüência disso, no caso de linguagens de programação, o curso oferece o Delphi como ambiente para desenvolvimento de software comercial. Sendo o Delphi baseado na linguagem Object Pascal, é natural que essa linguagem também seja utilizada em algumas disciplinas, para preparar os alunos para o estudo de Delphi em Linguagem de Programação Comercial. E por quê Delphi? Por quê não VisualBasic? Se as duas linguagens (ObjectPascal e Basic) em que se baseiam os ambientes forem analisadas sob o aspecto de orientação a objetos a conclusão que se chega é que a abordagem de ObjectPascal é mais eficiente, principalmente quando se trata de herança. Apesar de Basic ser mais simples de ser aprendida que ObjectPascal, deve-se pensar em desenvolvimento em equipe, quando a orientação a objetos é fundamental, devido principalmente à reutilização de código. Ambas estão no grupo das chamadas Rapid Application Development (RAD), o que as tornam as mais populares para o desenvolvimento voltado para ambientes GUI (Interface Gráfica do Usuário). Segundo o índice TIOBE de setembro/2008 a linguagem Delphi é a décima mais popular do mundo. Ao se observar a lista, verifica-se que, Java é a primeira, VisualBasic a quarta e Delphi a décima. VisualBasic é mais popular que Delphi por ser a linguagem da Microsoft e não porque é melhor. As outras linguagens, pela nossa avaliação, não se enquadrariam no que se chama linguagem comercial e visual, e portanto ficam fora dessa discussão. De qualquer forma a opção por uma linguagem para desenvolver um sistema deve levar em consideração as necessidades do cliente. É uma decisão de projeto. Espera-se ter contribuído para justificar o estudo de mais de uma linguagem de programação no curso de Sistemas de Informação e também o porquê da opção pelo ambiente Delphi.

Minha paixão pela computação - I

No ano de 1976 entrei para o curso de Engenharia Elétrica - Opção Eletrônica na UFPa. Logo nos primeiros semestres fiz minha matrícula numa disciplina chamada "Introdução à Ciência da Computação". Após a tradicional introdução que conta a história do computador, passando pela numeração binária, iniciamos o estudo de algoritmos e fluxogramas. Veio então meu primeiro programa, na linguagem FORTRAN versão Monitor, muito usada no meio científico naquela época. O professor então nos instruiu como deveríamos proceder para, após criarmos o código do programa, testá-lo no computador da universidade. Hoje, nas aulas de laboratório do curso de Sistemas de Informação do CEULS, temos dois alunos por máquina, às vezes até um por máquina. Nem em meus sonhos mais otimistas conseguia imaginar isso. O fato é que tínhamos que compartilhar um único computador para todas as atividades da instituição. Era um IBM 1130. Esse computador tinha 16K palavras de 16 bits de memória e cada unidade de disco atingia a capacidade de 512k palavras. Algumas imagens dessa maravilha podem ser vistas em http://palazzo.pro.br/hist/ibm_1130.htm. Para testar um programa precisávamos digitar o código em uma máquina chamada perfuradora de cartões. Cada linha de código tinha no máximo 80 caracteres e era inserida em um cartão. Nesse cartão cada caractere inserido correspondia a uma seqüência de furos. Algum tempo na fila da perfuradora e vários cartões estragados depois, juntávamos aquele monte de cartões, chamado deck, e entregávamos a um atendente que protocolava. Dois dias depois de uma espera angustiante recebíamos o resultado: nosso deck de cartões e uma listagem do nosso código. Se tivesse funcionado, o resultado saia na própria listagem. Monitor de vídeo? LCD? O que é isso? E se não funcionasse? Bem, analisávamos a listagem conferindo sintaxe, ordem dos cartões (alguém esbarrou e cairam todos no chão!!!), lógica, etc. Mais algum tempo na fila da perfuradora, cartões inutilizados e nosso deck estava pronto para um novo teste. O ciclo se repetia até que tudo estivesse rodando perfeitamente. Essa história prossegue outro dia.

Análise de Sistemas

Análise é a tarefa de identificar e descrever os requisitos de um sistema, definindo a forma como ele deve funcionar para atender as necessidades de todos os interessados. A tarefa de análise define "o que" o sistema deve fazer sem se preocupar "como" será feito. Durante a análise são criados diversos modelos do sistema, que o descrevem em diferentes perspectivas e níveis de detalhe.
A análise é um mecanismo de comunicação e também um acordo entre os interessados. Na análise são definidas as funções que serão implementadas no sistema e, por conseguinte, as funções que não farão parte do escopo do mesmo.
Segundo Pressman, qualquer método de análise deve contemplar cinco atividades:

• Representar e entender o domínio da informação;
• Definir as funções que o sistema deve executar;
• Representar o comportamento do software em função dos eventos externos;
• Separar os modelos de informação, função e comportamento de maneira a apresentar os detalhes de forma hierárquica, e;
• Prover a informação essencial em direção à determinação dos detalhes de implementação.

Daí se pode deduzir que, além da análise de sistemas entender "o que" deve ser feito, ela deve utilizar uma representação que permita documentar e comunicar essa informação.

Modelos de Análise

Existem algumas propostas de modelos para descrever a análise de sistemas:

• Modelo de Negócio: descreve como funciona o negócio onde o sistema está inserido.
• Modelo de Dados: descreve os dados armazenados na forma de um modelo conceitual, utilizando o modelo entidades-relacionamentos.
• Modelo Funcional: descreve a funcionalidade essencial do sistema, utilizando o diagrama de fluxo de dados.
• Modelo Orientado a Objetos: descreve o sistema através dos dados e das funcionalidades, utlizando o diagrama de classes.

Ferramentas da Análise

O trabalho de análise é feito a partir da comunicação entre as pessoas interessadas. A comunicação, em geral, é feita da linguagem natural dessas pessoas, tais como o português, o inglês, etc. Um grande problema dessas linguagens é que elas permitem a formação de expressões ambíguas.
No desenvolvimento de sistemas deve-se evitar as duplas interpretações. Assim, deve ser utilizada uma linguagem de forma que uma sentença só tenha uma interpretação. Várias linguagens foram criadas, principalmente as gráficas, com o objetivo de restringir as ambiguidades e também de facilitar o entendimento por todos os interessados. Dentre essas ferramentas de análise podemos relacionar a Técnica Estruturada e a UML (Unified Modeling Language).

Cinco tipos de personalidades que você não quer em sua equipe

Há cinco tipos de membros de equipe de projeto que não queremos em nossos projetos - e que você não quer nos seus. Se você notar algumas dessas características abaixo em pessoas com quem você trabalha, você precisa agir para transformá-las em membros de equipe que todos os gerentes de projeto invejam.

O Cowboy: esta pessoa é selvagem e lunática. Cowboys não pensam duas vezes antes de incluir comentários inapropriados ao código, esconder ovos de Páscoa na aplicação, fazer remendos no escopo do projeto. Cowboys frequentemente são trabalhadores inteligentes e rápidos e gostam de ser criativos. Trabalhe com essas pessoas, estabelecendo regras e procedimentos, controle de qualidade, tal como revisões em pares, e conversas diretas sobre o que é permitido.

O Rato: o rato é uma pessoa tímida e retraída que precisa de sua instrução, aprovação e mão forte em cada ação que ela realiza. Ratos podem ser facilmente influenciados pelos membros da equipe, stakeholders, e pelos seus próprios medos de prosseguir no trabalho. Seu trabalho é ensinar os ratos a rugir construindo sua confiança e forçando-os a tomar decisões.

A Rocha: Duro, teimoso e difícil de mudar, esse é a Rocha. Rochas são as pessoas que geralmente tem anos de experiência e querem fazer as coisas à sua maneira porque é a maneira correta. São o tipo de pessoa que dizem, "Há duas maneiras de desenvolver uma aplicação: a minha maneira e a maneira correta - e elas são a mesma". Negocie com a Rocha para estabelecer um comando firme e segui-lo.

O Linguista: Linguistas adoram linguagem, e não sabem quando parar de falar. Suas conversas sem fim consomem tempo de projeto, de reuniões, e roubam tempo de outros desenvolvedores, que estão trabalhando em suas tarefas. Você tem que negociar com essas pessoas diretamente conduzindo-as à direção certa. Se um linguista perturbar a equipe de projeto, você tem que intervir ocasionalmente.

O Tio: Lembra do seu tio favorito? É o cara com todas as brincadeiras, estórias engraçadas e truques de mágica. Você adora o seu tio, mas não quer ele em seu projeto. Tios são normalmente trabalhadores rápidos e supõem que o resto da equipe trabalha tão rápido quanto eles. Dê a eles tarefas mais desafiadoras para garantir que eles não vão ficar entediados e começar a incomodar os ouvidos do restante da equipe.

Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.

A morte pela documentação

Frequentemente nós tendemos a pensar na documentação como um componente adicional a um projeto em vez de uma parte real do projeto. A verdade sobre este assunto é que a documentação pode fazer a diferença entre o sucesso e o fracasso de um projeto.

Vez após vez, organizações têm criado bons produtos mas não investido os recursos necessários em sua documentação. Muitos desses produtos se tornaram um fracasso de mercado, não por serem maus produtos, mas porque as pessoas não sabiam como usá-los.

Havia uma grande organização de software que costumava fazer bons pacotes de desenvolvimento. A versão 3 de um software desta companhia era muito bem aceito e tinha grande chance de se tornar a plataforma de desenvolvimento dominante em uma área específica.

Querendo dominar o mercado, a organização investiu todos os seus recursos na versão 4. A interface com o usuário foi mudada na versão 4. Mudaram as opções. Mudaram as chamadas. Mudaram tanto que os usuário teriam dúvidas se a versão 4 era o mesmo produto que a versão 3.

De fato, foi criado um produto de desenvolvimento que estava bem à frente de seu tempo e teria impulsionado dramaticamente a programação. O que aconteceu, na verdade, é que a coisa toda se inverteu e o software foi descontinuado. Enquanto isso, outra organização liberou o software de desenvolvimento que se tornou padrão de fato.

O que deu errado? Como essa organização falhou tão miseravelmente?

Ela vendeu o produto por dois preços. Pelo primeiro preço a empresa entregava apenas a mídia. Pelo segundo preço (quase duas vezes mais) entregava aos usuários a mídia e milhares de páginas de manuais de como usuá-lo.

Muitos programadores pensaram que mudando da versão 3 para a versão 4 estariam fazendo uma mudança evolucionária, e não compraram os manuais. Sem os manuais, os desenvolvedores se perderam sem conseguir imaginar como fazer o que eles precisavam fazer. Frustrados e aborrecidos, os desenvolvedores abandonaram o pacote.

Aqueles que adquiriram os manuais foram literalmente esmagados pelos milhares de páginas espalhadas por cinco livros que se referenciavam mutuamente de tal modo que os usuários tinham que ter todos os livros abertos ao mesmo tempo de maneira a imaginar como fazer o que precisavam fazer. Estes que gastaram o dinheiro extra também abandonaram a nova plataforma.

Naturalmente a plataforma morreu; não porque não era boa, mas porque a documentação a matou. Documentação escrita adequadamente, empacotada adequadamente como um produto de qualidade, deveria impulsionar a empresa para uma posição invejável.

Quando você projetar sua documentação, tenha em mente essa história e assegure que seus produtos não se tornem presa do mesmo fato. Esta catástrofe é bastante fácil de prevenir, mas você deve fazer um esforço consciente de fazer isso.

Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.

Sobre Requisitos e Projeto

"A parte individual mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita errado. Nenhuma outra parte é mais difícil de consertar depois" (Fred Brooks).
"É melhor saber algumas das questões a todas as respostas" (James Turber).
"O milagre mais comum da engenharia de software é a transição da análise para o projeto e do projeto para o código" (Richard Due).
"Você pode usar uma borracha na prancheta de desenho ou uma marreta no canteiro de obra" (Frank Lloyd Wright).
"Um erro comum que as pessoas cometem quando tentam projetar algo completamente seguro tem sido subestimar a engenhosidade dos inteiramente doidos" (Douglas Adams).

Engenharia de Software - Uma história de amor e ódio

Palestra de Christian Reis na Feira de Informática 3.0 de 2003 na UFSCar. Eis alguns pontos:
- A profissão moderna mais difícil;
- Exige conhecimento técnico detalhado em uma área em constante ebulição;
- O que eu espero de vocês é que tenham paixão pelos seus produtos, e com estes produtos, que ajudem a construir o Brasil;
- Se não tiverem paixão pelos seus produtos me avisem para eu nem pensar em ser um consumidor;
- Esqueçam suas aulas: desenvolver software (de qualquer maneira) é Engenharia de Software;
- Não se enganem: escrever código, rodar e testar é um processo de software;
- O que nos falta é uma visão de escala: para que tipos de tarefas são adequados que tipos de processo;
- Obviamente, a preocupação com processo de software é menor quando é um projeto de 3 horas;
- Processo de Software é um nome chique para descrever quando sentamos juntos e planejamos construir ou consertar algo:

• Descobrir o que tem para ser feito.
• Descobrir como será feito.
• Fazer. Fazer. Fazer. Fazer.
• Descobrir se faz mesmo o que era para fazer.
  (enxague, repita)

- Para aprender como construir software, precisamos de bons exemplos;
- Nenhum processo bem projetado é burocrático, inútil ou sem resultado. Mas o processo tem que se encaixar na sua equipe;
- Engenharia de Software é para ser divertido e interessante (e seu amigo na hora que dá tudo errado);
- Engenharia de Software ensina ter amor pela equipe, amor pelo usuário, amor pelo produto;
- Engenharia de Software é uma passo em direção à evolução da profissão;
- "Pessoas que dizem que algo não pode ser feito não devem interromper quem está fazendo" (Provérbio Chinês)

O que é Engenharia de Software?

Engenharia de Software é uma disciplina que reúne metodologias, métodos e ferramentas a ser utilizados, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software (CARVALHO, 2001).
Engenharia de Software é a criação e a utilização de sólidos princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais (NAUR apud PRESSMAN, 2006).
Engenharia de Software é: (1) aplicação de uma abordagem sistêmica, disciplinada e quantificável para o desenvolvimento, operação e manutenção do software; isto é, a aplicação da engenharia ao software. (2) o estudo de abordagens como as citadas em 1 (IEEE, 1993).