Archive for the Ensino de engenharia de software Category

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

A questão são as questões

Posted in Ensino de engenharia de software on September 22, 2009 by José Augusto Fabri

Atualmente, para efetivar a contratação de um colaborador as empresas levam em consideração toda a bagagem das competências comportamentais de um candidato. Saber lidar com situações conflitantes, ser assertivo, comunicar-se muito bem com os demais colaboradores e, principalmente, utilizar de forma eficaz todo o know-how adquirido durante o processo de formação, são diferenciais importantes a qualquer profissional.

Contrapondo as expectativas das empresas, os cursos superiores, responsáveis pela formação do profissional, não detectam e desenvolvem as tais competências. É consensual que durante o período escolar o aluno é permeado por avaliações pontuais e “conteudistas”. A maioria dos professores considera que o momento da avaliação consiste em apenas aplicar aquelas provas que caracterizo como tradicionais. Nela o aluno deve responder questões objetivas ou de múltipla escolha, exemplo: Monte a tabela verdade para a expressão p v q ^ r e assinale a resposta correta. “Cá entre nós, esta questão avalia a competência do aluno?“

De posse dos fatos afirmo que, dentre os vários problemas inerentes ao processo de avaliação, encontramos o formato das provas, ou seja, a questão são as questões.

Para os cursos que trabalham as competências da engenharia de software, que tal elaborarmos provas que contenha outro formato… Neste post sugiro um exemplo.

O texto abaixo se caracteriza como um cartão de estória que deve ser implementado por um grupo de 3 alunos. Dois alunos irão trabalhar em par e o terceiro será responsável por garantir a qualidade na execução do processo e conseqüentemente a do produto. O processo de produção do software é caracterizado pelas seguintes atividades.

 a)       Projeto de software: Esta atividade possui duas tarefas

  1. Prototipação: é necessário materializar o protótipo do projeto.
  2. Estabelecer o modelo de classes que será utilizado no projeto.

b)        Planejamento de Produção – nesta atividade os alunos deverão:

  1.  estabelecer o tamanho do produto a ser desenvolvido.
  2. estabelecer o prazo em horas para o desenvolvimento do produto.

c)        Codificação: O software deverá ser codificado em JAVA respeitando as prerrogativas da orientação a objeto. Utilize a técnica de par-programming para executar essa atividade. Desenvolva o software respeitando o JAVA CODE CONVENTION.

d)       Teste:  Durante esta atividade os alunos deverão:

  1. Definir os dados de testes. Utilize para isto as técnicas de particionamento em classes de equivalência, a análise do valor limite e o teste funcional sistemático.
  2. Executar os testes.
  3. Apresentar formalmente o relatório dos testes.

e)       Gestão do projeto: A gestão do projeto é feita paralelamente a todas as atividades. O gerente deverá trabalhar diagramas de Gantt.  Esses diagramas devem apresentar a evolução gerencial do projeto.

f)        Gestão de Configurações: Todos os artefatos gerados devem ser geridos quanto a sua configuração – utilize para isto o cvs ou o subversion.

Tempo para desenvolvimento do programa: 16 horas

Após o desenvolvimento do programa, os alunos deverão elaborar um relatório que aponte as suas potencialidade e fragilidades perante ao processo.

O cartão: Quermesse (retirado do site da OBI)

Os alunos do último ano resolveram organizar uma quermesse para arrecadar fundos para a festa de formatura. A festa prometia ser um sucesso, pois o pai de um dos formandos, Teófilo, dono de uma loja de informática, decidiu doar um computador para ser sorteado entre os que comparecessem. Os alunos prepararam barracas de quentão, pipoca, doces, ensaiaram a quadrilha e colocaram à venda ingressos numerados sequencialmente a partir de 1. O número do ingresso serviria para o sorteio do computador. Ficou acertado que Teófilo decidiria o método de sorteio; em princípio o sorteio seria, claro, computadorizado.

O local escolhido para a festa foi o ginásio da escola. A entrada dos participantes foi pela porta principal, que possui uma roleta, onde passa uma pessoa por vez. Na entrada, um funcionário inseriu, em uma lista no computador da escola, o número do ingresso, na ordem de chegada dos participantes. Depois da entrada de todos os participantes, Teófilo começou a trabalhar no computador para preparar o sorteio. Verificando a lista de presentes, notou uma característica notável: havia apenas um caso, em toda a lista, em que o participante que possuia o ingresso numerado com i, havia sido a i-ésima pessoa a entrar no ginásio. Teófilo ficou tão encantado com a coincidência que decidiu que o sorteio não seria necessário: esta pessoa seria o ganhador do computador.

Tarefa

Conhecendo a lista de participantes, por ordem de chegada, sua tarefa é determinar o número do ingresso premiado, sabendo que o ganhador é o único participante que tem o número do ingresso igual à sua posição de entrada na festa.

Entrada

A entrada é composta de vários conjuntos de teste. A primeira linha de um conjunto de teste contém um número inteiro positivo N que indica o número de participantes da festa. A linha seguinte contém a seqüência, em ordem de entrada, dos N ingressos das pessoas que participaram da festa. O final da entrada é indicado quando N = 0. Para cada conjunto de teste da entrada haverá um único ganhador.

Exemplo de entrada

 4

4 5 3 1

10

9 8 7 6 1 4 3 2 12 10

0

Saída

Para cada conjunto de teste da entrada seu programa deve produzir três linhas. A primeira linha identifica o conjunto de teste, no formato “Teste n”, onde n é numerado a partir de 1. A segunda linha deve conter o número do ingresso do ganhador, conforme determinado pelo seu programa. A terceira linha deve ser deixada em branco. A grafia mostrada no Exemplo de Saída, abaixo, deve ser seguida rigorosamente.

Exemplo da saída

Teste 1

3

Teste 2

10

(esta saída corresponde ao exemplo de entrada acima)

Restrições

0 ≤ N ≤ 10000 (N = 0 apenas para indicar o fim da entrada)

Ao analisar a prova, percebemos que:

1 – o aluno deve possuir conhecimentos relacionados a processo de produção de software (algumas práticas imersas nos processo ágeis são delineadas).

2 – aspectos relacionados à usabilidade são avaliados quando solicitamos o protótipo do software.

3 – as macro-atividades da gestão de projetos – planejamento, execução e controle – são solicitadas pelo processo.

4 – padronização de código e conhecimentos relacionados a testes de software também permeiam o processo.

5 – a gestão de configuração é um aspecto que também deve ser avaliado.

6 – orientação a objeto e Java, conteúdos técnicos relacionados à programação e modelagem também são solicitados na prova.

6 – situações conflitantes, assertividade e a comunicação entre os membros da equipe caracterizam-se como aspectos qualitativos não técnicos, estes por sua vez DEVEM ser avaliados – uma boa deixa para o pessoal que trabalha com os aspectos relacionados aos recursos humanos.

7 – a elaboração do relatório, além de promover uma auto-reflexão do aluno frente a avaliação, pode expressar a forma de comunicação escrita do grupo – uma boa deixa para os professores de língua portuguesa.

É importante ressaltar que esse tipo de prova deve ser acompanhado por um grupo de professores. Fatores quantitativos e qualitativos que irão compor a avaliação devem ser bem delineados pelo grupo em um momento anterior a prova.

Por fim, gostaria de salientar que a configuração da prova e o momento de aplicação deve atender os conteúdos que compõem o projeto pedagógico (aqui apresento apenas um exemplo). A prova também não deve eliminar a avaliação individual do aluno, essa sim deve ser feita pelo professor durante o curso normal da disciplina.

Fica a sugestão…  

Abraços

José Augusto Fabri – fabri@femanet.com.br

Follow

Get every new post delivered to your Inbox.

Join 37 other followers