Educação em Engenharia de Software

Junho 20, 2008 by Julio Cesar Sampaio do Prado Leite

O Simpósio Brasileiro de Engenharia de Software está iniciando, este ano, um encontro com o objetivo de discutir a educação em Engenharia de Software.

O evento foi chamado de Fórum de Educação em Engenharia de Software.

A expectativa dos organizadores é de que esse fórum reunirá pessoas que reconheçam a necessidade de uma formação adequada para a construção de software.

Espera-se que além da comunidade acadêmica, a comunidade de desenvolvedores de software e as empresas produtoras de software tenham também interesse e participem desse evento que procurará trocar experiências sobre como ensinar e treinar bons profissionais de engenharia de software.

Visite a página do evento: fees.inf.puc-rio.br

A Necessidade da Abstração (A Visão do Poeta)

Maio 17, 2008 by Julio Cesar Sampaio do Prado Leite

Em nota anterior, “Níveis de Abstração“, já tinha apontado da importância do conceito de abstração para a engenharia de software.

Posterior a minha postagem, o Professor Jeff Kramer publicou um artigo na CACM cujo título é “Abstraction – the key to Computing?” onde escreve sobre porque acredita que esse conceito é fundamental para a computação. Concordo plenamente. Vale a pena ler.

Estive na UFF no árduo trabalho de membro da banca de um concurso para Professor.   Nesta ocasião,  o Professor Orlando Loques mostrou-me um conto de Jorge Luis Borges que tinha pregado em sua parede. Incrível! Creio que é uma demonstração clara da necessidade da abstração.  Aqui vai o texto, leia-o com atenção.

Del rigor en la ciencia

En aquel Imperio, el Arte de la Cartografía logró tal Perfección que el Mapa de una sola Provincia ocupaba toda una Ciudad, y el Mapa del Imperio, toda una Provincia. Con el tiempo, estos Mapas Desmesurados no satisficieron y los Colegios de Cartógrafos levantaron un Mapa del Imperio, que tenía el Tamaño del Imperio y coincidía puntualmente con él. Menos Adictas al Estudio de la Cartografía, las Generaciones Siguientes entendieron que ese dilatado Mapa era Inútil y no sin Impiedad lo entregaron a las Inclemencias del Sol y los Inviernos. En los Desiertos del Oeste perduran despedazadas Ruinas del Mapa, habitadas por Animales y por Mendigos; en todo el País no hay otra reliquia de las Disciplinas Geográficas.
Suárez Miranda: Viajes de varones prudentes
Libro Cuarto, cap. XLV, Lérida, 1658 (veja a fonte)

Se preferir ouvi-lo na própria voz do grande poeta, veja este vídeo.

——–

Leia sobre Sistemas de Informação.

Veja a página do autor.

W/Brasil

Março 5, 2008 by Julio Cesar Sampaio do Prado Leite

Há mais de dois anos, estou para escrever sobre um trecho do livro, “Na toca dos leões” de Fernando Morais , que relata a história da agência W/Brasil: “uma das agências de propaganda mais premiadas do mundo”, conforme o subtítulo do livro.

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.

Transparência – Contas Nacionais

Janeiro 18, 2008 by Julio Cesar Sampaio do Prado Leite

Um dos aspectos importantes de todo indivíduo ou organização é controlar suas despesas, para no mínimo saber onde estão sendo utilizadas as receitas auferidas. Quando as despesas são de uma organização com vários sócios, esses sócios certamente gostariam de saber como as receitas estão sendo utilizadas, isto é, onde o dinheiro recebido está sendo gasto.

Pois bem, um estado também tem sua contabilidade, e no caso os cidadãos deveriam saber onde o dinheiro está sendo gasto. No entanto, poucos, normalmente economistas, ficam interessados em analisar as contas nacionais. Essa semana uma notícia no jornal O Globo me chamou a atenção: falava de um relatório do Ipea sobre Despesas Correntes da União. Fiquei curioso e fui dar uma lida. Recomendo que vejam a tabela 3 (página 15) do referido artigo. A tabela mostra que o Brasil gasta em despesas financeiras (pagamento de empréstimos) 34,1% (2006) do total de suas despesas correntes! Por que?

Porque como diz o autor do artigo, os juros relacionados a essas despesas são juros altos. Veja o que diz Ronaldo Coutinho Garcia o autor do relatório.

Mas a principal causa do crescimento das Despesas Correntes da União não foi o aumento dos gastos sociais ou com pessoal. Quem mais impulsionou o crescimento das DCUs foram as despesas com juros e encargos da dívida. Dado que a dívida pública mobiliária federal interna, em valores reais, foi multiplicada por sete, entre 1995 e 2006, e tem sido remunerada com taxas de juros sempre das mais altas do planeta[0], é inevitável que pressione por aumento da carga tributária, comprima os investimentos públicos, exija superávits primários elevados e, mesmo assim, não pare de crescer.” (Ipea: texto para discussão 1319)

Ou seja, o país gasta mais em pagamento de juros do que com despesas referentes à manutenção da máquina governamental, já que, com pessoal os gastos são 13,42% (2006) de todas as despesas e transferência para estados e municípios são da ordem de 15,90% (2006) de todas as despesas.

Portanto quando serviços básicos que deveriam estar sendo fornecidos pelo estado brasileiro deixam de ser, é bom saber como a “organização” está gastando os recursos.

Pense sobre isso.

——–

Leia sobre Sistemas de Informação.

Veja a página do autor.

Acoplamento e Coesão

Dezembro 17, 2007 by Julio Cesar Sampaio do Prado Leite

A semana passada, descobri que alguns alunos falharam ao explicar o que seria acoplamento e coesão. Pensando sobre o assunto, cheguei a conclusão que, em minha nota sobre o tema modularidade, havia a necessidade de uma melhor explicação sobre esses conceitos

Vou tentar.

Acoplamento é uma medida “inter” componentes. Isto é, é uma medida entre componentes de um conjunto. No caso de um sistema é uma medida do relacionamento entre sub-sistemas. No caso de um programa composto de funções, é uma medida do relacionamento entre funções. Os dois espectros dessa medida: são alto acoplamento e baixo acoplamento. Componentes que têm baixo ou fraco acoplamento são considerados mais independentes um do outro. O inverso vale para alto ou forte acoplamento.

Coesão é uma medida “intra” componentes. Isto é, procura medir um componente individualmente. No caso de um sistema, mede-se a coesão de cada sub-sistema. No caso de um programa organizado por funções, mede-se a coesão de cada função. A coesão pode ser alta ou baixa. Obter coesão alta é imprescindível em todo sistema bem organizado. Entende-se coesão alta, quando os integrantes de um componente estão relacionados a um tema comum, isto é tem o mesmo objetivo, fazem uma única coisa. A coesão alta é também conhecida como coesão funcional. Um bom indicativo de componentes com baixa coesão é o título ou nome do componente: todo componente que utiliza-se do conector e ou do conector ou é um forte candidato para ser classificado como tendo baixa coesão. Veja que o título dessa nota (propositalmente) apresenta uma baixa coesão.

——–

Leia sobre Sistemas de Informação.

Veja a página do autor.

Faz Diferença

Dezembro 6, 2007 by Julio Cesar Sampaio do Prado Leite

O jornal O Globo, através do sítio do Globo Online, está promovendo uma enquente sobre personalidades que se destacaram no ano de 2007.

Vale a pena conferir e votar.  É uma maneira de conhecer pessoas e organizações que procuram melhorar a sociedade ou destacam-se no que fazem.

Apesar do cunho regional, Rio de Janeiro, creio que vale para todos, são vários os exemplos que se aplicam a outras regiões.

———

Leia sobre Sistemas de Informação.

Veja a página do autor.

Revista Digital de Biblioteconomia e Ciência da Informação

Novembro 19, 2007 by Julio Cesar Sampaio do Prado Leite

Incrível (Amazing)!

Acabei de descobrir uma revista digital publicada pela Unicamp. Trata-se da revista “Revista Digital de Biblioteconomia e Ciência da Informação”. Anotei no Delicious como “vou ler”.

Passei os olhos sobre dois artigos, um sobre ontologias e outro sobre sistemas de informação. É incrível notar a interdisciplinaridade e a ausência de comunicação entre as comunidades de pesquisa de ciência da computação e da ciência da informação.

Só como um exemplo: no texto sobre ontologias é feita uma vasta pesquisa bibliográfica sobre o tema e lista-se apenas um item publicado em Português. Ocorre que, no escopo de pesquisa, pelo menos um outro artigo já tinha sido publicado sobre o tema e não foi incluído no resultado. Se a base usada tivesse sido o Google Scholar isso não teria ocorrido.

Se por um lado, uma área desconhece o trabalho da outra, e no caso apenas citei um exemplo, é impressionante que a área de Ciências de Informação já tenha seu periódico de acesso livre na rede desde 2003 com artigos em Português. Estão de parabéns! Enfim uma lição a ser aprendida.

O periódico está implantado sobre uma plataforma criada na Universidade de British Columbia chamada “Public Knowledge Project” que foi uma das inspirações para a Biblioteca Digital da comunidade de Engenharia de Requisitos.

Outro exemplo a ser aprendido diz respeito à atenção a transparência sobre o processo editorial (veja o fluxograma). Exemplo a ser seguido!

(27/11/07): O Professor Asterio Tanaka informou sobre um projeto do IBICT sobre publicações digitais. Vale a pena conferir. Também vale lembrar o papel do Scielo como uma pioneira na publicação digital (veja nota anterior sobre isso).
—–

Leia sobre Sistemas de Informação.

Veja a página do autor.

Simpósio Brasileiro de Engenharia de Software (SBES)

Outubro 27, 2007 by Julio Cesar Sampaio do Prado Leite

Reproduzo abaixo mensagem que enviei à lista da Sociedade Brasileira de Computação.

O evento que reuniu o XXI SBES e o XXII SBBD aconteceu na semana
passada na Paraíba.

O SBES atingiu a maioridade. Gostaria de observar que essa
maioridade é apropriada.

Quem esteve em João Pessoa presenciou um congresso
dinâmico e muito bem organizado.

A maioridade é presente também no nível de debate e nos
temas discutidos. Reflete, sem dúvida, a constante preocupação
da comunidade em manter o SBES como um marco para a atividade
de pesquisa em Engenharia de Software. Escutei alguns comentários
sobre o SBES como uma incubadora de eventos, e
isso é notável, ou seja, além de fomentar que grupos de interesse
ganhem autonomia, mantém a tradição da reunião de
muitos (creio que por volta de 500 pessoas) centrados nos
assuntos da pesquisa em Engenharia de Software.

Um das perguntas freqüentes que o SBES se faz é sobre a interação da
comunidade com a indústria. No painel sobre isso, foi perguntado à
platéia, quem vinha da indústria. Creio que cerca de 2% dos presentes
levantaram a mão. No entanto, um dos membros do painel,
o Professor Don Batory, lembrou da importante missão da pesquisa
atrelada às universidades. Segundo sua visão, é aí onde reside a
principal fonte de transferência de conhecimento: os alunos, que
serão os futuros profissionais. O SBES é fundamentalmente um lugar
para o debate de resultados de pesquisas e, portanto, mais próximo
do interesse acadêmico. Creio que isso é positivo.

A integração com a indústria se dá, e se dará como, importante,
efeito colateral.

Em uma das sessões técnicas foi apresentado um trabalho
que surgiu da colaboração entre uma universidade e uma empresa
de software, porque esta empresa assistiu, no ano anterior no SBES,
uma apresentação da ferramenta da universidade. É obvio que isso
é só um exemplo, mas é um fato concreto.

Enfim: na verdade, a mensagem era para agradecer ao
comitê organizador e ao comitê de programa. Fizeram um excelente trabalho. Parabéns!

jcl

Em comemoração aos 21 anos do SBES, coloco aí ao lado, uma página com elos para artigos publicados no simpósio bem como para as páginas dos simpósios desde de 1998. Quem tiver endereços para eventos anteriores, favor informar, que atualizarei as informações.

—–

Leia sobre Sistemas de Informação.

Veja a página do autor.

Três Pontos Fundamentais

Agosto 27, 2007 by Julio Cesar Sampaio do Prado Leite

Um engenheiro de software para ter sucesso em sua profissão precisa de conhecimento em três áreas.

Além desses conhecimentos é necessário que o engenheiro de software fique atento a três pontos fundamentais. São eles:

Primeiro ponto: A definição do software sempre está relacionada à implantação de outro artefato(s), que eventualmente pode ainda não estar implantado ou terminado. Em muitas situações, onde os artefatos hospedeiros ainda estão sendo desenhados, os conceitos de engenharia concorrente (veja aqui em Português) precisam ser utilizados. Ou seja, o processo de construção de um artefato tem um paralelismo com o processo de construção de outro. Para definir-se um software, seria o ideal que o artefato hospedeiro estivesse “pronto”, mas muitas vezes isso pode não ocorrer. Esse primeiro ponto tem como fonte principal o artigo da Professora Mary Lou Maher, “Process Models for Design Synthesis”.

Segundo ponto. Diferentes interessados (atores) do Universo de Informações podem ter opiniões diferentes sobre constituintes ou componentes do Universo de Informações. Portanto o processo de engenharia de requisitos, que construirá a definição do software, tem que entender que podem existir diferentes opiniões e lidar com esse fato. Diferentes pontos de vista podem ser conflitantes e precisam ser mapeados e discutidos. Esse processo pode necessitar de atividades de negociação entre os interessados. Um ponto positivo em mapear diferentes pontos de vista é que o processo de resolução de conflitos aumenta o conhecimento sobre o Universo de Informações. Veja o artigo “Viewpoints on Viewpoints”. Se tiver mais interesse no tópico, veja um sítio dedicado ao tema.

Terceiro ponto. Os desenvolvedores de software podem escolher qual o conjunto de métodos, técnicas e ferramentas (MTFs) querem utilizar no processo de produção. A seleção de um conjunto de MTF´s, deve depender do contexto. Não existem MTF´s que sejam unanimidade, portanto essa variedade é presente nos processos de produção e dependem, como dito, do universo de informações. O conceito de perspectiva está diretamente ligado a este ponto. A escolha de MTFs embutem a escolha de como, o software será modelado, isto é sob qual perspectiva. Uma perspectiva impõe restrições sobre o que pode ser modelado e com que ênfase. Uma modelagem orientada a dados, impõe uma perspectiva distinta de uma modelagem orientada a processos.
…………

Leia sobre Sistemas de Informação.

Veja a página do autor.

Triângulo do Conhecimento

Agosto 26, 2007 by Julio Cesar Sampaio do Prado Leite

Para produzirmos software temos que ter fundamentalmente três tipos de conhecimento: conhecimento da engenharia de software, conhecimento do contexto (Universo de Informações) em que o software será aplicado e conhecimento da máquina computacional da qual o software fará parte.

triang-conh.jpg

O conhecimento da engenharia de software permite que o engenheiro tenha proficiência no uso de métodos, técnicas e ferramentas.

O conhecimento do contexto é adquirido com a ajuda das MTFs.

O conhecimento da máquina computacional é proporcionada pela fundamentação teórica em várias disciplinas da ciência da computação.

O grande desafio da engenharia de software é prover MTFs que ajudem os engenheiros de software entenderem o contexto onde o software irá atuar e as limitações da máquina computacional em que o software irá residir. Para isso é inevitável que o engenheiro de software trate o problema da transição de descrições informais para descrições formais e que também modele adequadamente as restrições da máquina escolhida. Essa máquina computacional é uma combinação de hardware e software. Portanto, vale notar que quando produzimos software, temos que levar em consideração outros software já pre-existentes na máquina computacional escolhida.

Essa idéia é fundamentada na visão de Peter Freeman sobre os conhecimentos necessários ao engenheiro de software.
…………

Leia sobre Sistemas de Informação.

Veja a página do autor.