Temos uma ótima notícia para os interessados em Engenharia de Software em geral e Engenharia de Requisitos e Experimentação em particular.

O CIbSE (CIbSE, WER e ESELAW) está com um programa de altíssimo nível: palestra principal a ser proferida pelo Prof. Lucena falando da Ciênca da Web e a Engenharia de Software, quatro tutoriais sobre importantes aspectos da Engenharia de Software (qualidade, ontologias, estatística e ISO/IEC 29110), e mais de 30 palestras .

http://cibse.inf.puc-rio.br/

É uma excelente oportunidade para aqueles que querem conhecer mais sobre Engenharia de Software, bem como para aqueles que já fazem pesquisas na área.

Além disso, teremos um painel com profissionais com experiências importantes na Engenharia de Software em contextos distintos: IBM, Accenture e Concrete Solutions.

Tudo isso no Campus da PUC-Rio, aqui no Rio de Janeiro, que, como bem lembrou o Presidente Obama, é a Cidade Maravilhosa. Então é uma ótima oportunidade para aprender mais sobre Engenharia de Software e conhecer ou rever o Rio.

Esperamos vocês.

Confira o programa: http://cibse.inf.pucrio.br/files/CIbSE_WER2011_Program.pdf

Outra coisa: peço um favor,: se conhece alguém que tenha interesse em Engenharia de Software, mas que deixe de ver essa nota, repasse-a. É sem dúvida uma excelente oportunidade tendo em vista a alta qualidade do evento.

Obrigado.

Uma das coisas que me chamou a atenção foi uma citação do livro “Structure and Interpretation of Computer Programs“, livro que recomendo (veja elo aí do lado) que resumo dessa maneira: “Livro obrigatório para quem quer aprender a programar. É difícil, mas é essencial.” A citação em questão é: “Thus, programs must
be written for people to read, and only incidentally for machines to execute.” (Programas devem ser escritos para que pesssoas os leiam e apenas incidentalmente para que máquinas os executem). Ou seja programas devem ser escritos para que possam ser lidos por humanos, e para isso precisam ser transparentes.

Recomendo dois textos do autor: “Hackers and Painters” e “Five Questions about Language Design” ele tem uma visão que poderia ser chamada de baixo-para-cima, mas creio que o principal é sua visão do engenheiro de software (aquele que escreve software) como um explorador de alternativas, e por isso sua ênfase em flexibilidade.

Um de seus projetos é a construção de uma nova linguagem, a qual batizou de Arc. Nada posso falar dessa linguagem, mas gostei dos três principios gerais que norteiam seu uso/construção:

1) Esteja preparado para mudar, já que Arc vai evoluir em função de sua própria adoção.
2) Use o forum: idéias, sugestões dúvidas devem ser compartilhadas.
3) Programação exploratória: Arc está sendo feita com esse foco, o de tornar a tarefa de programar menos burocrática e portanto mais divertida.

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.

Refiro-me ao artigo Requirements Monitoring in Dynamic Environments de Steven Fickas e Martin Feather.  

Além desse artigo, creio ser importante também ler o artigo Requirements-based monitors for real-time systems de Peters e Parnas. 

Outro pesquisador que está estudando monitores no contexto de requisitos é Bill Robinson, que recentemente publicou Implementing Rule-Based Monitors within a Framework for Continuous Requirements Monitoring.

Comecei manifestando pesar e tristeza pelos eventos ocorridos em São Paulo. Difícil de entender, de aceitar e de conviver, mas os fatos são verdadeiros. Houve tantas mortes como em Carandiru (que ocorreu em 1992! –14 anos — o que aprendemos?).

Nesse contexto, relatei reportagem da Folha de São Paulo que mencionava o fato de que a solicitação dos repórteres sobre a lista dos mortos até o dia 17/5 não tinha sido fornecida (na nota “Em 12 horas, polícia mata 33 suspeitos em SP”). O órgão de impressa estava pedindo transparência.

Por outro lado, citei um artigo que tinha acabado de ler na Communications of the ACM (Vol. 49, N.1) sobre Neo-Tribes. No caso os pesquisadores mostravam como uma comunidade virtual na área de saúde pode dividir conhecimento para o bem comum. Ótimo exemplo de transparência.

Falei também de minha surpresa com a composição acionária da Petrobrás. Julgava que a companhia tinha a maior parte de seu capital em mãos de brasileiros, ou melhor, do governo brasileiro. No entanto, pude verificar no próprio portal da companhia que isso não é mais assim (vide progressão do capital de 1992 até 2005). Isso é outro exemplo de transparência.

Utilizei apenas três exemplos, mas são vários outros. Esses exemplos vão à direção do tema de minha palestra. A sociedade está e estará exigindo, cada vez mais, transparência nas decisões ou nos acontecimentos que dizem respeito aos seus cidadãos.

Claro que a privacidade e a segurança nacional ou patrimonial são também exigidas pela sociedade, e claro é que esses fatores interferem ou sofrem interferência quando também se deseja transparência.

Fiz, também, uma analogia com o processo de auditoria financeira e contábil nas empresas. Esse processo de auditoria é baseado na transparência das informações reunidas no balanço das empresas, e que por lei tem que ser pública. Essa exigência é importante para o funcionamento do sistema de mercado. Com base nessas informações, investidores e governo podem tomar decisões. No entanto, há pouco tempo o mundo veio a conhecer graves problemas nesse sistema. O caso Enron foi uma amostra de como agentes sem escrúpulos estavam burlando essa transparência, e o país onde isso ocorreu providenciou a promulgação de uma legislação mais atualizada e mais rigorosa. Essa legislação conhecida como SOX (Sarbanes-Oxley Act of 2002.) teve grande impacto, também nos sistemas de informação.

Até aqui estava falando de transparência de informações.

No entanto, na medida em que nossas vidas vão ser cada vez mais regidas por software (software no celular, software na televisão, software no carro, software no controle de câmeras de vigilância, software de controle de acesso, software no exame do imposto de renda, software no controle de nossos ativos financeiros, software no controle de nossos registros médicos, …) a sociedade vai também exigir transparência nos software que estamos usando e que estão afetando nossas vidas.

Veja por exemplo o caso de celulares. Será que o software que está embutido no aparelho tem controle sobre os níveis de radiação a que estamos expostos? Segundo pesquisa na rede, fale-se que o FCC (Estados Unidos) obriga a que os celulares daquele país tenham circuitos do tipo GPS, ou seja, possam emitir sua exata posição (na verdade o tema do artigo relaciona-se a outro tema (o bug do ano 2000)). Não seria interessante que o usuário soubesse como o software do celular (cliente e servidor) está tratando essa informação?

Sim, mas o que a engenharia de software tem a ver com isso?

De que maneira a engenharia de software deve atuar no sentido de tornar o software um processo mais transparente? Na verdade, o que estamos a delinear é uma oportunidade de pesquisa. Nossa premissa baseia-se em que, no futuro, a sociedade vai exigir transparência do software. Cabe, portanto, a comunidade de pesquisa adiantar-se e procurar estudar como tornar o software mais transparente para aqueles que o usam ou que são afetados por eles.

Vale a pena frisar que não estamos querendo que o usuário do software interaja com o software no nível de programação, portanto não estamos falando de programação de software. Estamos falando da descrição do que o software está fazendo, no nível de compreensão do usuário. Essa diferença é sutil, mas extremamente importante.

Em termos de oportunidade de pesquisa, podemos usar o 5W2H, para esclarecer um pouco mais ao que estamos referindo.

O que? – Estudo de meios para tornar o software mais transparente, isto é para quem o utiliza saiba o que o software faz.

Por quê? – Como pesquisadores, devemos estar adiante das necessidades futuras, portanto, nos cabe investigar meios que tornem possível com que o software seja transparente.

Onde? – Nos produtos e nos serviços que usam software. No entanto aqui fica um dos desafios: de que maneira tornar transparente software embarcado (no seu telefone, no seu carro, no seu dvd, no avião, …).

Quando? – Esta questão de contexto está ligada a anterior, quando e em que freqüência um software deve ser visível.

Quem? – No nosso contexto, creio que nos, engenheiros de software, temos de tomar a dianteira e estudar meios de tornar o software mais transparente. No entanto, certamente no futuro haverá órgãos reguladores que poderão participar na operacionalização dessa transparência.

Como? – Claro, aqui reside o desafio. Como fazer com que o software seja transparente. São vários os desafios, tanto sob o aspecto de visualização ou de interface como o de confiabilidade, de performance, entre outros. Aqui reside o cerne do problema, como levar adiante o conceito de software transparente.

Quanto custa? – Claro que a sociedade haverá de pagar um preço, já que isso não virá sem esforço extra. Esses aspectos serão importantes, mas creio que, a princípio, sejam coadjuvantes.

Já podemos pensar que há indícios de como isso poderia ser feito. Duvida? Então dê uma olhada no “Exibir Código-Fonte” disponível no seu navegador. Aqui está o embrião da transparência de software. Claro, muitos são os obstáculos, mas se o tema lhe parece desafiador então pense em juntar-se ao nosso time.