Para que fique mais transparente minha afirmação, reproduzo aqui o texto encontrado no
Relatório de Desenvolvimento Humano 2009 /2010,
Brasil Ponto a Ponto: consulta pública, PNUD, Brasília, 2009, página 22.

“Além do desafio de desenvolver uma metodologia
para transformar essa informação qualitativa
em quantitativa, para que pudéssemos
sistematizar e comparar as visões de diferentes
pessoas, precisou-se lidar com visões integradas,
nas quais as pessoas relacionavam vários temas
ao mesmo tempo. Com isso, os temas foram subdivididos
em temas setoriais (educação, saúde,
violência etc.) e em temas transversais (que são
aqueles temas comuns a vários assuntos ou
setores, como valores, desigualdade etc.).”

A partir de 2008 o governador da Califórnia, Arnold Schwarzenegger, vem tentando cortar o enorme déficit do estado, e uma das medidas que procura implantar é limitar os pagamentos dos funcionários.

No entanto, o controlador do estado, responsável pela folha de pagamentos dos servidores estaduais, argumenta que mudar o sistema de pagamentos, escrito em Cobol, é uma tarefa que geraria mais prejuízos para o estado.

O impasse chegou aos tribunais, que recentemente emitiram uma ordem para que a mudança de salários seja implantada.

É  o software, cada vez mais,  sendo percebido como importante pela sociedade em geral.

Vejam a nota original em Inglês.

O primeiro é para, mais uma vez,  mostrar como o software torna-se cada vez mais próximo do público de maneira geral. A foto abaixo mostra um anúncio feito pela Volks no jornal O Globo de 19 de outubro de 2009. A razão do anúncio é a substituição de um componente presente em dois tipos de veículos em função de defeito no componente. Só que o componente é software. É a primeira vez que vejo um “recall” de automóveis falando diretamente do software.

Enfim, mais um alerta para o papel fundamental da Engenharia de Software.

Outro ponto interessante é que um anúncio semelhante (veja abaixo) feito por outra empresa, na verdade pertencente ao mesmo grupo da Volks, a Audi aparece no mesmo jornal, mas em página diferente. Nele a Audi chama para um “recall” exatamente igual a chamada da Volks. Aqui , se pode inferir que as plataformas para produção dos veículos são basicamente as mesmas, isto é eles foram concebidos segundo a filosofia de Linha de Produto, algo que a indústria de software já utiliza também.

A empresa Telefônica, responsável pela infra-estrutura da rede no estado de São Paulo, divulgou um comunicado, do qual ressalto o seguinte parágrafo:

“Durante os trabalhos, os técnicos identificaram um software que entrou em pane, fazendo um roteador gerar rotas falsas de transmissão de dados por toda a rede. Isso dificultou a localização exata do problema. Foi necessário vasculhar todo o sistema para localizar este defeito, que estava em um roteador de Sorocaba. Assim que foi localizado, o roteador foi isolado, os dados desviados, e a rede voltou a funcionar.”

Interessante que a companhia tenha relatada a falha no software como pane. Software entra em pane? Procurando a palavra no dicionário achei: “s. f., avaria;
paragem acidental do motor de um veículo.” Curioso é que na rede o termo pane leva direto ao assunto (falha na rede da Telefônica). Apesar de não ser utilizado na literatura de engenharia de software, o termo pode tornar-se popular.

Outro fato curioso é a frase: “…identificaram um software que entrou em pane, …”. O que exatamente seria “um software”, seria um sistema, um pacote, um componente, um pedaço do código?

Enfim. Aos poucos a sociedade vai percebendo que “software” é algo que, apresentando problemas, pode causar sérios transtornos.

Este caso é mais uma razão para que software seja visto como um artefato que precisa de qualidade e de transparência. Afinal o que ocorreu?

Reportar o problema de maneira transparente é dever da empresa. O espírito das investigações deve seguir a máxima de que o problema deve ser identificado para que não ocorra em outras situações, a mesma política que norteia investigações de acidentes aéreos. Aqui vale lembrar o relatório produzido pela cidade de Londres sobre o caos gerado naquela cidade quando da falha do sistema de despacho de ambulâncias.

——–

Leia sobre Sistemas de Informação.

Veja a página do autor.

O livro é uma leitura obrigatória para profissionais que lidam com organizações, e neles incluo engenheiros de software. O autor é um especialista em biografias e domina o ofício de entrevistar e relatar o elicitado, além disso, como todo biografo, faz uma coleta e seleção de documentos relevantes ao tema do livro. No caso desse livro, a biografia dos personagens principais é vista em função da empresa que fundaram e muito do livro retrata os detalhes de funcionamento de agências de publicidade. Creio que aqui o autor demonstrou ser um excelente etnógrafo, face à clareza com que reporta o observado ou o imaginado ante os depoimentos colhidos.

No capítulo 11 o livro diz:

“Para pôr em prática o que acreditava ser uma nova concepção do funcionamento de uma agência, Washington tomou algumas providências básicas logo nos primeiros dias. A primeira delas foi extinguir uma entidade que até hoje sobrevive em muitas agências: o tráfego, segundo ele “uma instituição pré-histórica”:

- O que era o tráfego? Os caras da criação achavam os do atendimento burros e caretas, e os caras do atendimento achavam os da criação porras-loucas e irresponsáveis. Dos dois lados, gente ganhando uma puta grana. Então a agência contratava uns mocinhos e umas mocinhas para transportar pedidos e informações de um lado para o outro e, assim, neutralizar esse atrito.

Na opinião de Washington, além de custar caro, o tráfego era um canal a mais para diluir a informação entre criação-atendimento-cliente, nos dois sentidos. Convencido de que aquilo só atrapalhava o processo, no primeiro dia de funcionamento da W/GGK ele decretou:

- Esta agência não terá tráfego.

A segunda medida foi estimular o pessoal da criação a fazer aquilo que o ajudara a transformar-se num empresário: apresentar pessoalmente as campanhas aos clientes. Quem não quisesse estava desobrigado da tarefa, mas a cultura que ele pretendia implantar se resumia em duas frases:

1. A criação não manda o anúncio para o cliente, ela apresenta o anúncio.

2. O atendimento não passa o briefing. Ele é o briefing. “

Na toca dos leões, Fernando Morais

Algumas organizações produtoras de software abusam do “tráfego” e distanciam-se dos clientes. É bom ter em mente os princípios utilizados pela W/Brasil. Em particular chamo a atenção para uma nota anterior sobre o que profissionais de implantação (criação) pensam sobre os profissionais de requisitos (atendimento).

——–

Leia sobre Sistemas de Informação.

Veja a página do autor.

Uma nota do Estado de São Paulo na edição “on-line” do dia 8 de Dezembro entitulada “Sargento assume culpa por apagão; FAB descentraliza controle de vôo
Brigadeiro admite que identificação de problema na 3.ª-feira levou mais de 6 horas por
falta de técnico especializado” de autoria de Vera Rosa, Tânia Monteiro e Bruno Tavares, diz, no seu final, o seguinte:

“O terceiro – e mais grave – apagão nos aeroportos em pouco mais de um mês começou a se desenhar na manhã de terça-feira. Às 9 horas, controladores detectaram interferências corriqueiras nas freqüências de rádio usadas por aviões que decolam do Rio para Brasília. Como o chiado dificultava o contato com as aeronaves, o supervisor acionou um dos sargentos que cuidam da manutenção dos equipamentos.

O sargento desviou algumas freqüências para a central de áudio reserva, que funciona conectada e concomitantemente à titular. A transferência é feita por chaves eletrônicas – o operador direciona as freqüências para cada máquina clicando numa tela de computador. Só então o sargento percebeu que a central reserva estava inoperante – passava por manutenção. ‘Depois que você faz a troca das freqüências para outra central, o software não aceita a contra-ordem’, disse um oficial.

Ao tentar desfazer o erro, o sargento inverteu uma placa, piorando a situação. ‘É como se você colocasse pilha num rádio ao contrário’, disse um ministro. O militar abandonou a sala técnica, sem avisar os superiores. ‘Essa ‘barbeiragem’ desconfigurou o sistema’, afirmou outro militar. “

 A reportagem inicia-se com a frase: “O maior apagão da história da aviação brasileira foi causado por falha humana.”. O termo apagão foi cunhado pela imprensa por lembrar a crise de energia que o país passou no fim do século passado. Outro ponto a ressaltar é o emprego do termo “falha” ao ínves de “falta”, veja nota anterior sobre isso.

No entanto, o que pode ser mais grave é que, na verdade, o problema esteja não no erro cometido pelo humano, mas em erros cometidos no desenho do software que controla essas centrais. Ainda é cedo para se saber o que realmente ocorreu, o que relatei acima foi uma reportagem de jornal, mas a característica da globalidade de sistemas torna cada detalhe de grande importância, principalmente em situações onde se depende de software.

p.s. Em função da escrita dessa nota, acabei escrevendo outra, em outro veículo.

…………

Leia sobre Sistemas de Informação.

Veja a página do autor.

Esse tipo de software possibilita a comunicação do cliente (seu computador) com o servidor (o sítio que você acessa) através de um conjunto de padrões, tanto de codificação como de protocolos.

A idéia base do Ajax é explorar assincronicidade, possibilitada pela divisão de tarefas, ou seja o cliente pode estar trabalhando independentemente do servidor. Com isso pode-se fazer interfaces mais sofisticadas e melhorar a performace da aplicação, que passa a explorar as capacidades do lado cliente.

As letras do Ajax: “A” vem assincronicidade, “ja” vem de Javascript (é necessário que a máquina virtual Java esteja habilitada no lado cliente) E “x” que vem de XML que é o padrão de codificação utlizado para transporte entre o programa javascript do lado cliente para o servidor.

Um grupo de alunos da PUC-Rio trabalhou numa interface do tipo Ajax e agregaram esta interface ao software livre C&L. Vejam uma demonstração desse protótipo.

Sua palestra está organizada em transparências implementadas em html e php usando ccs. Gostei da implementação, é coerente com software livre.

Ele procura, de certa maneira, contestar o ensino clássico de engenharia de software. Em alguns pontos equivoca-se:"desenvolver software (de qualquer maneira) é Engenharia de Software.". Claro que não é. Aí reside o grande diferencial de quem estudou Engenharia de Software.

No entanto, ele está correto ao afirmar que " escrever código, rodar e testar é um processo de software".

O ponto importante é: existem processos que são mais bem definidos que outros e que são mais produtivos que outros. O conhecimento de ES permite escolher processos. Aqui é chave entender que, para escolher bem, é necessário ter um conhecimento prévio. É certo que um processo não serve para todos os casos. Cada caso é um caso. No entanto estará melhor quem conhece as vantagens e desvantagens de cada tipo de processo.

Gostei de visão de processo da transparência 5. Principalmente do enxague e do repita. O enxague é o passar a limpo, o repita é utilizar a visão de retro-alimentação, fundamental em qualquer aprendizado.

Gostei também da reclamação da falta de bons exemplos. Tem razão. Muitas vezes exigimos que os alunos aprendam errando, quando o ideal seria o de aprender lendo bons exemplos.

Como é de senso comum: para escrever é preciso ler. No entanto, em software encontrar boas leituras não é fácil. Muitas são as razões. No entanto, vai abaixo uma lista que pode ajudar. Pena que os exemplos estão em Inglês…

Para um projeto de software veja aqui.

Para exemplos de códigos veja aqui e aqui. Para ver algo que deve ser evitado veja aqui.

Se souberem de bons exemplos em Português avisem. Existem bons exemplos em Português, claro, estou me referindo a estarem disponíveis na rede.