A primeira rede social sobre arquitetura de software do Brasil

O que ensinar em Engenharia de Software?

Já que estamos em um grupo Professores, lá vai o desafio de sempre: o que ensinar em Engenharia de Software na graduação? Normalmente são duas disciplinas de 60 horas com algumas variações (algumas são de 75 ou 90 horas), e esse tempo não é suficiente para fazer os alunos botarem a mão na massa prá valer. E a quantidade de tópicos e assuntos é muito grande, e nós professores temos esse desafio: como organizar essas disciplinas, de forma tal que o aluno saia delas com conhecimento de fundamentos e com alguma prática? Eu tento uma mudança todos os anos, melhoro tópicos, mudo a forma de aplicar o projeto, os resultados não mudam muito. Mas, por exemplo até hoje não consegui entrar com Métodos Ágeis prá valer, não dá tempo de fazer isso. Minha melhor experiência foi a desse último semestre de 2008, na Eng. Software II: adotei o livro do Raul Wazlawick "Análise e projeto de sistemas de informação orientados a objetos" como manual de projeto, dividi o projeto em quatro partes, cada parte associada com um grupo de capitulos do livro, cobrindo o livro todo de cabo a rabo. O projeto foi relativamente simples (recomendo que façam o mesmo), Agenda remota para telefones celulares (que agora descobri que a TIM oferece como serviço para quem tem os chips de 128k), e deixei os alunos darem asas a imaginação. Junto com a terceira fase do projeto, cada grupo preparou um protótipo para testar o projeto e corrigir eventuais falhas, e foi muito bom, tipo competição com os próprios alunos avaliando o trabalho dos colegas. Paralelamente, eu andei com as aulas teóricas cobrindo os tópicos relativos a cada parte do projeto, no mesmo ritmo do próprio projeto, dentro da filosofia de Eng. Software baseada em Processos. Tentei seguir um modelo de disciplina baseado em PBL-Project Based Learning, e gostei muito da experiência. Está lançado o tópico, vamos à discussão... zeluis (essa mensagem vai pro blog em breve, aumentada e comentada)

▶ Responder esta

Respostas a este tópico

Permalink Responder até Eros Viggiano em 18 janeiro 2009 at 19:11: Apesar de não concordar inteiramente com a terminologia, creio que a melhor referência na área é o SWEBOK. O corpo de conhecimento (que na verdade é um grande indexador) aponta as áreas de conhecimento da engenharia de software e apresenta a taxonomia de Bloom para um curso de gradução de 4 anos. Claro que deve ser adequado para outros cursos como Ciência da Computação, Sistemas de Informação, Engenharia da Computação, etc. Mas serve como uma diretriz sólida para qualquer um deles. Aproveitando que o forum do Pangea é arquitetura de software, cito o nível de conhecimento de arquitetura esperado de um aluno de gradução.

SOFTWARE DESIGN
3. Software structure and architecture
Architectural structures and viewpoints | AP
Architectural styles (macroarchitectural patterns) | AN
Design patterns (microarchitectural patterns) | AN
Families of programs and frameworks | C

Onde, resumidamente, C=Comprehension, AP=Application, AN=Analysis. Existem outros níveis no domínio cognitivo.

Lamentavelmente os cursos do mercado, apesar da ênfase evidente na produção de software, apresentam muito pouco conteúdo em engenharia de software (a própria carga horária que você mencionou revela o fato). Na última semana, olhei a grade curricular de três cursos de pós-graduação em engenharia de software e achei lastimável. Um deles está completamente obsoleto. Os outros dois estão mais relacionados a temas fúteis, superficiais, ligados a modismo e limitados pela incapacidade de professores e coordenadores.

De uma forma idealista (e talvez um tanto utópica), sugiro que você procure ensinar nos níveis recomendados pelo SWEBOK. Caso você seja coordenador ou tenha alguma influência sobre ele, vale a pena tentar adequar a carga horária para atingir tais níveis.

Te desejo muita sorte e paciência.; ▶ Responder esta

Permalink Responder até Jose Luis Braga em 19 janeiro 2009 at 8:09: Olá, Eros. Bom, SWEBOK sempre foi um bom guia, todas as minhas disciplinas seguem o contexto do SWEBOK, tanto as da graduação quanto as do mestrado. Desse ponto de vista, estamos bem fundamentados. O problema que estou colocando é sobre como implementar, em uma disciplina de graduação de poucas horas, os temas recomendados de forma tal que o aluno aprenda alguma coisa, e que as aulas não sejam apenas uma enxurrada de transparências, normas e regras. O desafio, prá mim, está ai: motivar a geração Y a meter a mão na massa e aprender os conceitos com prazer e dedicação. Abraço,; ▶ Responder esta

Permalink Responder até Adriano Tavares em 20 janeiro 2009 at 18:46: Jose Luis,
Eu também já usei o livro do Dr. Raul "Análise e projeto de sistemas de informação orientados a objetos" que você citou. Foi em uma disciplina de Análise de Sistemas. O que me motivou foi a abordagem do livro mostrando o desenvolvimento de um sistema de informações guiado pelo processo unificado da concepção até a transição passando pela análise e desenho com UML e o excelente material complementar de apoio ao professor. Como não poderia ser diferente, em se tratando do processo unificado, a arquitetura também é trata no livro ver os tópicos: Modelagem Dinâmica, Camadas de Domínio, Interface e Persistência.
Acredito que o "processo de desenvolvimento de software" é o ponto fundamental que deve ser abordado em disciplinas de Engenharia de Software. De acordo com o autor é possível cobrir o conteúdo em disciplinas de 40 ou 60 horas.

abs; ▶ Responder esta

Permalink Responder até Jose Luis Braga em 21 janeiro 2009 at 5:47: Olá, Adriano. Esse livro do Raul é baseado no livro do Craig Larman, Utilizando UML e padrões, que é excelente do ponto de vista de processos. Foi minha primeira experiência com ele na graduação, pois acho que os alunos de graduação estão em fase de aprender conceitos bem aprendidos, e eu uso regularmente o livro de Engenharia de Software do Wilson de Pádua, apenas os fluxos de Requisitos, Análise e Projeto, que correspondem a iterações de Concepção e Elaboração (entro muito pouco em projeto que é dado em outra disciplina). Já usei várias vezes o livro do Raul em disciplinas de pós-graduação, tanto lato-sensu quanto Mestrado, com muito sucesso, o livro é de auto-aprendizado, a gente atua apenas como facilitador e indutor, que é o melhor papel que podemos assumir. Na última edição da minha disciplina na graduação, dei um problema interessante em prova, para puxar a criatividade e imaginação dos alunos. Fiquei tão entusiasmado com o resultado, que fiz uma postagem no meu blog sobre ele, está em http://zeluisbraga.wordpress.com/2008/10/12/boas-praticas-no-desenv.... A intenção da questão da prova era botar na cabeça dos alunos que o mundo de desenvolvimento de software não gira somente em torno de CMMI, mpsBR e outras, tem muito espaço para crescer em qualidade adotando as melhores práticas, que são alvos mais atingiveis para as micro-empresas (que são a esmagadora maioria das empresas de desenvolvimento). Abs,; ▶ Responder esta

Permalink Responder até João Carlos Ferreira Barbosa em 1 abril 2009 at 16:18: Bom, nem tanto "o que ensinar", mas talvez mais na linha do "como" ensinar, eu realmente gostei bastante da proposta do IGTI pro curso de pós em Engenharia de Software Aplicada:

http://www.institutogti.com.br/index.php?option=com_cursos&task...

Bom, sou meio suspeito pra falar, já que muitos dos caras que estão lá são amigos/colegas, mas realmente recomendo a visita.; ▶ Responder esta