Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reformulação da linha de Engenharia de Software #7

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ranisalt
Copy link
Collaborator

Idéia um pouco diferente do planejado em #4, e inspirado neste paper de Dijkstra.

Como ambas as ementas de ES I e II eram praticamente iguais, com várias seções se sobrepondo (por exemplo, ambas as matérias devem ensinar "metodologias de análise e projeto"), uni a primeira e a segunda ementas, e alterei completamente a primeira disciplina para ensinar mais sobre como gerenciar código e a segunda sobre como gerenciar projetos, tornando-a optativa.

A ideia é que a matéria ainda obrigatória ensine aspectos importantes da organização de programas, como programar testes, utilizar versionamento, integração de código, etc. que são completamente ignoradas no currículo atual. Quem realmente deseja ser um gerente de projeto pode pegar a segunda matéria optativa.

Também removi a matéria de planejamento e gerência de projetos, por julgar que isso foge demais de ciência da computação. Se alguém desejar, há matéria equivalente no curso de sistemas da informação (INE5617) que pode ser selecionada como optativa.

Não deve haver grandes mudanças, já que o egresso de ES II vai ter o mesmo conhecimento que tem hoje, só numa ordem diferente e com prioridade em aplicação real.

@mateusduboli
Copy link
Contributor

@ranisalt Tem um projeto da UC Berkley sobre o uso do Github na instituição aqui.

Eles fazem contribuições para grandes projetos OpenSource no Github. Pelo que o vídeo mostra, os alunos procuram esses projetos e escolhem uma feature para implementar.

Acho que esse formato pode ser utilizado por exemplo no Capim, agora sob a tutela do PET e talvez procurar projetos brasileiros como o LibreOffice.

Esse tipo de contato com o mundo prático torna a matéria muito mais interessante, e traz uma satisfação a mais para os alunos, vendo seus projetos sendo utilizados por diversas pessoas.

@paladini
Copy link

@mateusduboli , só um comentário acerca do MatrUFSC: existe outra versão do MatrUFSC que está sendo desenvolvida pelo @fjorgemota e está muito mais organizada (o código-fonte está com mais engenharia): https://github.com/matrufsc2/matrufsc2

@ranisalt
Copy link
Collaborator Author

@paladini não saia do escopo da issue

@mateusduboli concordo muito com essa questão. Na verdade, acho que é uma baita experiência de engenharia de software lidar com softwares open-source, já que muito mais do que trabalhar com 40 pessoas numa empresa em prol de um produto, você trabalha com talvez milhares de outros programadores diferentes em um produto voltado a um público bem maior, geralmente.

Particularmente acho que meu código melhorou muito depois que comecei a lidar com o mundo open source. É muito bom trabalhar com código diferente do seu, e pensar fora da caixa para lidar com muito mais arquiteturas do que é possível ver em sala de aula.

Quando você deu o exemplo do capim, seria algo muito gratificante ter um serviço do tipo programado e melhorado pelos alunos do próprio curso. Vale lembrar que o capim não é só o MatrUFSC, é também o MatrUSP e já foi cogitado o uso em outras universidades, então encaixa bem no que eu disse de um público bem maior.

E não digo só desse serviço. Tem outras coisas na UFSC, como aquele app do cardápio do RU e o Minha UFSC, ou até mesmo extraoficialmente o Professor Boiada. Todos feitos por alunos da UFSC que vem muito a calhar no tema :)

@paladini
Copy link

Desculpe, @ranisalt .

Concordo plenamente com a linha de raciocínio exposta, acredito que os trabalhos de engenharia de software seriam melhor aproveitados e também muito mais estimulantes dessa forma. Entretanto, acho que não podemos fugir do cunho prático: caso todos apoiem tal mudança, isso deveria estar presente no plano de ensino / ementa das disciplinas ou apenas como uma instrução extra-oficial aos professores para que optem por fazer isso?

Digo isso pois se a resposta à pergunta anterior for de que não é possível colocar tal informação nos planos de ensino, não faz muito sentido debater aqui, visto que não poderíamos fazer nada relacionado a reforma curicular para mudar isso (apenas convencer os professores extra-oficialmente).

Podemos colocar isso em uma reforma curricular?

@mateusduboli
Copy link
Contributor

Sobre a questão que isso seria uma mudança positiva, acho que todos concordamos que sim.

Do ponto de vista prático, não é preciso isso explicito na ementa da disciplina, já que nela, é feito o desenvolvimento de um projeto.

Uma forma de colocar isso seria propor ao professor a alternativa de, ao invés de desenvolver um projeto do zero, faz-se a análise de requisitos e da documentação de um desses projetos e desenvolve-se apenas algumas features.

Não sei quem é o professor atual da disciplina, mas podemos chamar ele para essa discussão.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants