Archive for the Ensino de engenharia de software Category

Engenharia de Software, CREA, SBC, ACM e ENADE

Posted in Ensino de engenharia de software on July 4, 2014 by José Augusto Fabri

O Conselho Regional de Engenharia e Agronomia (CREA) é uma autarquia responsável pela regulamentação das empresas e profissionais da área das engenharias clássicas, suas ramificações, como tecnólogos, técnicos industriais. É importante salientar que todo conselho regional é subordinado ao conselho federal – CONFEA.

O CONFEA surgiu em 11 de dezembro de 1933, por meio do Decreto nº 23.569, promulgado pelo presidente, Getúlio Vargas.

Atualmente, o CONFEA é regido pela Lei 5.194 de 1966, e representa também os geógrafos, geólogos, meteorologistas, tecnólogos dessas modalidades, técnicos industriais e agrícolas e suas especializações.

O objetivo do CREA e do CONFEA é:

Resguardar o interesse público e a ética no exercício das profissões das Engenharias, da Agronomia, das Geociências, das Tecnológicas e Técnicas, buscando sua valorização, através da excelência na regulamentação, organização e controle destas profissões” (fonte CREA-PR e CONFEA).

O curso de Engenharia de Software não é regulamentado pelo CREA.  É importante salientar que o referido curso é relativamente novo – a proposta pedagógica do curso é direcionada pela Association for Computer Machinery (ACM) e pelas diretrizes curriculares MEC desenvolvida em sua grande parte pela Sociedade Brasileira de Computação.

Outro fato de extrema importância, destacado neste texto, é a regulamentação da profissão na área de Informática (incluindo a Engenharia de Software).

A comunidade científica da computação vem trabalhando na regulamentação da profissão de Informática desde a década de 70.

Fruto dos debates ocorridos ao longo dos anos, nos diversos encontros de sua comunidade científica, em relação às vantagens e desvantagens de uma regulamentação da profissão de informática, a Sociedade Brasileira de Computação consolidou sua posição institucional em relação a esta questão pela formulação dos seguintes princípios, que deveriam ser observados em uma eventual regulamentação da profissão:

Exercício da profissão de Informática deve ser livre e independer de diploma ou comprovação de educação formal.

Nenhum conselho de profissão pode criar qualquer impedimento ou restrição ao princípio acima.

A área deve ser Auto-Regulada.

Os argumentos levantado junto à comunidade da SBC e que nortearam a formulação dos princípios acima estão detalhados na Justificação que acompanha o PL 1561/2003, o qual é integralmente apoiado pela Sociedade de Brasileira de Computação.

Fonte: homepage da SBC:

http://www.sbc.org.br/index.php?option=com_content&view=category&layout=blog&id=324&Itemid=964

Desconheço qualquer regulamentação para Engenharia de Software em outros países.

Outro fato que direciona inúmeros questionamentos é Exame Nacional de Desempenho dos Estudantes (ENADE) do curso Engenharia de Software. Neste ano serão avaliados os cursos de:

Arquitetura e Urbanismo; Sistema de Informação; Engenharia Civil; Engenharia Elétrica; Engenharia de Computação; Engenharia de Controle e Automação; Engenharia Mecânica; Engenharia Química; Engenharia de Alimentos; Engenharia de Produção; Engenharia Ambiental; Engenharia Florestal; Engenharia; Ciência da Computação; Ciências Biológicas; Ciências Sociais; Filosofia; Física; Geografia; História; Letras-Português; Matemática; Química; Artes Visuais; Educação Física; Letras-Português e Espanhol; Letras-Português e Inglês; Música; Pedagogia e os de Tecnologia em Análise e Desenvolvimento de Sistemas; Automação Industrial; Gestão da Produção Industrial e Redes de Computadores.

Perceba que o curso de Engenharia de Software não faz parte da lista, neste caso os formandos de 2014 estão isentos de participar do ENADE.

Por fim, em relação às questões que compõem o ENADE, tenho a plena convicção que teremos questões direcionadas a Engenharia de Software, assim como ocorre com os cursos de Licenciatura em Computação, Ciência da Computação, Engenharia da Computação e Sistemas de Informação – vide prova de 2011.

Qualquer dúvida sobre o curso por favor me escrevam.

José Augusto Fabri – fabri@utfpr.edu.br

Desenvolvendo habilidades da engenharia de software nas séries iniciais dos cursos de computação

Posted in Ensino de engenharia de software on June 12, 2013 by José Augusto Fabri

A maioria das universidades e faculdades da área de computação preocupam-se, no primeiro ano do curso, em ensinar técnicas de programação para os seus alunos, esquecendo das questões relacionadas à qualidade do processo que envolve este tipo de atividade. No primeiro ano, a atividade de programação é vista de forma isolada, muitas vezes os professores se esquecem que tal atividade está conectada, diretamente, com outras: projeto do programa (algoritmo no português estruturado ou no fluxograma) e teste formal. Com base nesta informação é possível afirmar que o aluno, ao ter contato com o desenvolvimento de um programa em uma determinada linguagem, executa, no mínimo, quatro atividades do processo de produção de software (vide Tabela 1).

Ao analisar a Tabela, é possível verificar que a abordagem proposta nas disciplinas de Programação é diferenciada. O aluno, ao implementar um programa, não tem mais contato apenas com um enunciado de uma determinada lista de exercício, ambos: ele e o professor encaram o antigo enunciado como um requisito ou uma funcionalidade do software.

Outro ponto pode ser destacado, o aluno não parte direto para programação, ele é obrigado a desenvolver um fluxograma do algoritmo, que irá atender ao requisito funcional para um determinado cliente, neste caso o professor da disciplina.

Na atividade de implementação, o professor da disciplina salienta a importância de se utilizar um padrão de codificação (o padrão adotado pelo professor é baseado no Código de Convenção JAVA). Além de utilizar o padrão de código, o aluno desenvolve o controle de versão do programa utilizando o CVS.

A atividade de teste é dividida em:

  • Teste interno: O professor divide a sala em grupos, geralmente cada grupo possui 4 alunos. Cada grupo recebe um conjunto de funcionalidades para testar, respeitando a seguinte restrição: O grupo NÃO pode testar uma funcionalidade desenvolvida por um de seus integrantes. Na execução da atividade de teste interno, a célula de teste deve definir: 1) Os casos de teste – quais os atributos que devem ser testados para aquela funcionalidade – para a definição dos casos de teste o aluno respeita este checklist. 2) O dado de entrada (em nosso caso a célula de teste pretende entrar com X para o campo sexo). 3) As saídas: esperadas e obtidas – salienta-se que a célula de teste é responsável por verificar se a redação do programa respeitou a convenção de código estabelecida.
  • Teste de aceitação: O teste de aceitação diferencia-se do teste de interno em apenas um aspecto: O teste é efetuado pelo cliente (o professor) na presença do desenvolvedor (o aluno).

Caso o programa não obtenha sucesso durante a atividade de teste, o mesmo deve ser corrigido pelo aluno – configurando assim o retrabalho.

Além de executar todas as atividades do processo, o aluno deve desenvolver a atividade de planejamento do projeto. Nela, ele estabelece um tempo para execução de cada atividade. Durante a execução do processo, tal cronograma sofre alterações e no final o aluno compara o tempo orçado com o realizado.

Por fim, noções de rastreabilidade de requisitos, também são implementadas na disciplina, lembre-se que a implementação de um programa depende de um enunciado em uma lista de exercício (em nosso caso uma funcionalidade), de um projeto de algoritmo apresentado em fluxograma (ou portugol) e, por fim, o programa será melhorado, constantemente, até chegar a um produto que agrade ao cliente. Tudo isto está interligado e pode ser rastreado.

José Augusto Fabri – fabri@utfpr.edu.br

Tutorial sobre pontos por função

Posted in Ensino de engenharia de software, gestão de projetos, processo de produção de software on April 9, 2013 by José Augusto Fabri

Pessoal, tomei a liberdade de gravar alguns vídeos (caseiros) durante a construção de  um tutorial sobre a pontos por função.

Antes de acessar os vídeos é importante ler este texto.

.

.

.

Fabri – fabri@utfpr.edu.br

Iteração de projeto ou de produto?

Posted in Ensino de engenharia de software, gestão de projetos, Introdução a Engenharia de Software on October 10, 2012 by José Augusto Fabri

A iteração é uma fatia de tempo definida dentro do projeto em que a equipe de desenvolvimento entrega uma versão estável e executável do produto (em nosso caso – um software). Além da entrega da versão, a iteração prevê também que a equipe disponibilize toda a documentação de apoio, scripts de instalação ou similares, necessários para usar a referida versão. É importante salientar que o executável é demonstrável, permitindo que a equipe apresente o real progresso do projeto aos stakeholders. O objetivo da iteração é obter críticas sobre o trabalho de modo que se possa melhorar compreensão do que necessita ser feito durante a execução (do restante) do projeto. Saliento que a iteração é construída com base nos resultados da iteração precedente, e reflete a um incremento de produto. As iterações possuem um marco definido no cronograma.

Eu, particularmente, classifico uma iteração em 2 tipos.

  • Iteração de projeto (ou pré-iteração): momento em que a equipe de desenvolvimento se reúne para verificar se os artefatos gerados durante a execução do projeto estão consistentes. Por exemplo: a) os pacotes de trabalho estabelecidos na EAP estão elencados no cronograma. b) o processo para a produção foi contemplado durante o desenvolvimento dos artefatos. c) o tempo estabelecido (previsto) para o desenvolvimento do trabalho foi respeitado. d) é necessário (re)planejar alguma fase do projeto. A iteração de projeto tem como objetivo estabilizar (parcialmente ou totalmente) um conjunto de artefatos. Perceba que este tipo de iteração não prevê necessariamente a entrega de um produto executável e sim artefatos que demonstre o progresso da equipe para os stakeholders.
  • Iteração de produto: Este tipo de iteração prevê a entrega de um produto executável, juntamente com todos os artefatos de projeto gerados durante a execução do processo. O produto entregue é estável e utilizável, neste caso ele deve gerar (ou aumentar) o valor agregado para o cliente.

Quando utilizar a iteração de projeto e quando utilizar a iteração de produto?

A de projeto pode ser utilizada pela equipe de desenvolvimento para verificar se o projeto está caminhando como o planejado. É interessante que este tipo de iteração seja sistematizada a aconteça com certa freqüência.

A de produto deve ser utilizada quando novas versões executáveis do produto são estabilizadas. Ela pode acontecer em uma freqüência menor se comparada com a primeira. Importante: Este tipo de iteração também deve ser sistematizada e demarcada no cronograma de execução do projeto.

Para finalizar, questiono: Como desenvolver uma boa iteração (de projeto ou de produto)?

Abraços

José Augusto Fabri – fabri@utfpr.edu.br

Dica: Video-Aulas sobre Linguagem C

Posted in Ensino de engenharia de software, Introdução a Engenharia de Software on September 18, 2012 by José Augusto Fabri

Pessoal, compartilho com vocês um link que possui uma série de vídeo-aulas sobre a linguagem C. Vale a pena dar uma olhada.

Abraços

J. A. Fabri – fabri@utfpr.edu.br

Boas práticas para um arquiteto de software

Posted in Ensino de engenharia de software, Introdução a Engenharia de Software on December 1, 2010 by José Augusto Fabri

O arquiteto de software é responsável pela materialização dos requisitos funcionais e não fucnionais de um um projeto. Escolher um bom framework de desenvolvimento e conhecer os padrões  para solução de um determinado problema faz parte do trabalho deste personagem.

Neste post apresento algumas práticas de devem ser seguidas por um arquiteto de software:

1 – Não basta escolher o um determinado framework, é necessiário acompanhar como ele está sendo utilizado pela equipe de produção.

2 – Flexibilidade – a arquitetura deve ser flexivel e adaptável as requisitos funcionais delineados pelo cliente.

3 – Lembre-se, as escolhas de um arquiteto influem direamente na produtividade da equipe. Produzir em uma estrutura bem montada é mais fácil.

4 – Conheça os frameworks, isto evita a subutilização. Lembre-se que eles são limitados.

6 – Aplique as boas práticas da engenharia de software em qualquer projeto.

7 – Suje as mãos, desenvolva algumas funcionalidades, tenha a visão dos programadores frente a uma arquitetura.

Abraços

José Augusto Fabri – fabri@utfpr.edu.br 

Ensinando UML para cegos

Posted in Ensino de engenharia de software on July 27, 2010 by José Augusto Fabri

No primeiro semestre de 2010 tive a oportunidade de colaborar na redação do artigo, ensinando UML para estudantes cegos.

Resumo do artigo

A inclusão de um estudante cego em um curso superior da área de informática não é uma tarefa simples, neste segmento de curso existe uma série de disciplinas que trabalham a especificação de software. Neste tipo de especificação são utilizadas notações gráficas (diagramas) que quase sempre não são acessíveis aos leitores de tela. Dado este contexto o presente trabalho tem como objetivo apresentar uma notação alternativa para o ensino de UML a um estudante cego do curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Universidade Tecnológica Federal do Paraná, campus Cornélio Procópio.

O artigo será publicado no Congresso Ibero-americano de Educação Superior em Computação de 18 a 22 de outubro de 2010. Neste ano o congresso será realizado em Assunção. Confira o artigo na íntegra acessando clicando aqui.

Aproveito a oportunidade para parabenizar os demais autores (Luciano e Cristiane) pelo trabalho realizado.

abraços

José Augusto Fabri – fabri@utfpr.edu.br

Implementando a residência de software em cursos de pós-graduação

Posted in Ensino de engenharia de software, gestão de projetos, mercado produtor de software, processo de produção de software, qualidade de software on June 22, 2010 by José Augusto Fabri

Pessoal, compartilho com vocês os resultados alcançados com a implementação/execução da residência em software no curso de pós-graduação da FATEC de Ourinhos.

Obtivemos a aprovação de um artigo na 40th. ASEE/IEEE – Frontiers in Education Conference.  

“The Frontiers in Education Conference (FIE) is one of the two major international engineering education conferences offered every year. The University of Virginia and Virginia Polytechnic Institute and State University will be this year’s host institutions. Over 600 academic and industry representatives are expected. Participants will include university presidents, college deans, department chairpersons, faculty in engineering, engineering technology, and computer science, as well as industry leaders from throughout the country and the world. The majority of the attendees, however, are computer science, engineering and engineering technology faculty”.

O artigo completo pode ser acessado pelo link http://www.fie-conference.org/fie2010/papers/1160.pdf.

Aproveito a oportunidade para parabenizar os professores Luiz Ricardo Begosso, Luiz Carlos Begosso, Fernando Cesar de Lima e Alexandre L’Erário, pessoas que não mediram esforços para o sucesso desta empreitada.

Ah… É possível acessar todos os artigos no site da conferência.

Abraços

José Augusto Fabri – fabri@utfpr.edu.br

SOA: Nome novo para a velha teoria – parte 2

Posted in Ensino de engenharia de software, Introdução a Engenharia de Software on November 3, 2009 by José Augusto Fabri

No último texto apresentei uma das raízes teóricas que originaram a orientação a objetos, recebi vários comentários e algumas questões, uma delas me chamou a atenção:

“Se eu partir do pressuposto apresentado no texto, posso concluir que SOA (arquitetura orientada a serviços) também é um nome novo para a velha teoria?”

O objetivo da arquitetura orientada a serviços é propor soluções para automatizar os processos de negócios. Aplicações que permitam aprimorar/dinamizar as tarefas manuais de uma organização são considerados elementos importantes em uma arquitetura orientada a serviços. A referida arquitetura possibilita aos usuários finais percepções e informações mais detalhadas e precisas de um processo de negócio. O acesso aos diversos níveis de informações (operacional, tático e estratégico) deve ser feito através da WEB ou por meio de um dispositivo móvel.  Pode-se dizer que SOA é fundamentada em 5 pilares:

  • Pessoa,
  • Processo,
  • Informação,
  • Conectividade,
  • Reuso de sistemas legados.

SOA possibilita o desenvolvimento de aplicações customizadas para o seu negócio, as facilidades para responder as demandas do mercado em uma economia globalizada é um benefício a ser considerado neste tipo de arquitetura.

É importante salientar que a implementação de uma estratégia consistente de componentização durante o processo de produção de software é uma das prerrogativas que delinearão o sucesso ou fracasso de uma estratégia SOA. O levantamento dos requisitos, a modelagem do processo de negócio, o desenho da arquitetura e o design das funcionalidades devem possuir grande consistência e, por fim, a reutilização de controle dos serviços já existente também faz parte das diretrizes que compõem uma arquitetura orientada a serviços.

Não quero jogar água no café de ninguém, mas ao analisar a definição apresentada concluo que:

Os analistas de sistemas trabalham com a modelagem de processos, organizam informações, estabelecem formas de conectar estações de trabalho e procuram reutilizar os sistemas já existentes a mais de 30 anos. Veja um velho e bom diagrama de fluxo de dados que você dará conta disto.  

Enfim, a evolução tecnológica é eminente e deve ser considerada (surgimento da WEB e dos dispositivos movéis), porém a quebra de um paradigma teórico não ocorre todo dia. Projetar uma aplicação orientada a serviços é sinônimo do desenvolvimento orientado a processo. Nome novo para a velha teoria.

Abraços

J. A. Fabri

fabri@femanet.com.br

Nome novo para a velha teoria – parte 1

Posted in Ensino de engenharia de software, Introdução a Engenharia de Software on October 21, 2009 by José Augusto Fabri

frameNa semana passada lá estava eu apresentando a idéia de mapas mentais para uma turma de último ano. Durante a aula um aluno me questionou:

Poxa professor… tu falas de uma teoria proposta em 1942, não existe nada mais atual para apresentar na aula?”

Por favor, me dê um exemplo!

“Posso enumerar vários artefatos que são mais novos que os mapas mentais, programação orientação a objetos (POO) e diagrama de classes são bons exemplos.”

Muito bem, quando surgiu tal forma de programar e tal diagrama?

Final da década de 1990, correto?

Não.

A programação orientada a objetos surgiu na década 1970 com a linguagem SIMULA, esta, por sua vez, era parte integrante da linguagem Smalltalk, desenvolvida pela Xerox PARC. Os conceitos sobre POO levaram mais de 10 anos para amadurecerem, por isso muitos dizem que a programação orientada a objetos é algo relativamente novo.

Já, segundo a minha singular visão, o diagrama de classes é uma adaptação do conceito de Frame popularizado por Marvin Minsky em 1975. Marvin propôs a aplicação do referido conceito na representação de conhecimento (veja a figura no início do post).

Na figura é possível encontrar dois frames, cada um representa um objeto do mundo real, algo bem parecido com o que conhecemos hoje como diagrama de classes.

Concluindo.

Ao trabalhar com POO e diagrama de classes lembre-se, estamos utilizando conceitos da década de 1970.

Deixo uma pequena provocação para os interlocutores deste blog:

É possível relacionar o conceito de mapa mental com frame? Será que a origem das classes não contempla as prerrogativas delineadas por Tony Buzan 1942?

Enfim, tudo nome novo para a velha teoria.

Abraços

J. A. Fabri

fabri@femanet.com.br

Follow

Get every new post delivered to your Inbox.

Join 38 other followers