Aplicação de Técnicas e Conceitos no Ensino de Engenharia de Software na Faculdade Lourenço Filho

Transcrição

1 Aplicação de Técnicas e Conceitos no Ensino de Engenharia de Software na Faculdade Lourenço Filho Emanuel Ferreira Coutinho Instituto UFC Virtual Universidade Federal do Ceará (UFC) Carla Ilane Moreira Bezerra Universidade Federal do Ceará (UFC) Campus Quixadá RESUMO Atualmente, o ensino tradicional de técnicas e conceitos de Engenharia de Software não tem sido muito efetivo no aprendizado, devido à falta de proximidade da teoria repassada com a prática aplicada no desenvolvimento de sistemas. A diversificação de técnicas de ensino traz uma série de benefícios aos alunos, pois estes assimilam melhor os conceitos. Neste contexto, este trabalho apresenta a aplicação de técnicas e conceitos de Engenharia de Software em sala de aula, visando à aproximação da execução das práticas no ensino com a aplicação real no desenvolvimento de software. Também apresenta uma análise dos resultados e feedback dos alunos em relação à execução das técnicas e conceitos. Palavras-chave: Engenharia de Software, conceitos. 1 INTRODUÇÃO Existe um consenso entre os docentes de disciplinas de informática que são necessários trabalhos práticos para que os alunos consigam assimilar o conhecimento transferido (TOMAYKO 1987, SCHNEIDER, 2003 e STEVENS, 2001). Segundo Silva (2004), especificamente na disciplina Engenharia de Software, estes estudos de caso normalmente são realizados de maneira a enfatizar a aprendizagem de aspectos tecnológicos, tais como linguagens de especificação, métodos e ferramentas de apoio. A diversificação de técnicas de ensino traz uma série de benefícios, como melhor assimilação dos conceitos, entendimento através de práticas ou jogos. Vários trabalhos de aplicações de técnicas, ferramentas e conceitos de Engenharia de Software vêm sendo publicados para disseminação da aplicação destas técnicas no ensino. Aguiar (2004) apresenta um modelo de processo de desenvolvimento de software denominado easyprocess, que tem como objetivo auxiliar na gerência do desenvolvimento de aplicações em

2 22 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 disciplinas da Engenharia de Software na graduação do Departamento de Sistemas e Computação da Universidade Federal de Campina Grande (UFCG). Já Soares (2004) descreve a experiência da utilização de trabalhos práticos na disciplina, como discutir vantagens e desvantagens de alternativas para a implantacão de um sistema, listar mitos da Engenharia de Software e explicá-los, descobrir ambiguidades ou omissões de uma especificação de requisitos e construção de diagramas UML em sala de aula a partir de especificações simplificadas. Em Lucena Jr. (2006) é descrita uma metodologia, com suas atividades e procedimentos, voltados ao ensino da disciplina de engenharia de software. Em Andrade (2008), é apresentada uma metodologia de ensino teórico-prática que consiste em incluir, em paralelo ao ensino teórico, o desenvolvimento de um projeto de software. Prikladnicki (2009) apresenta um conjunto de experiências de ensino em Engenharia de Software vivenciadas por quatro instituições de ensino superior no Brasil. Estas experiências foram planejadas e executadas a partir da identificação de desafios importantes, durante o processo de ensino nos últimos anos. Neste contexto, será descrita neste artigo a aplicação de alguns exercícios baseados em conceitos da Engenharia de Software, de uma maneira mais aplicada e integrada, na disciplina de Engenharia de Software. Além disso, será também apresentada uma análise dos resultados e feedback dos alunos em relação à execução das técnicas e conceitos. Este artigo está organizado como a seguir, além desta introdução: na Seção 2 são apresentados conceitos utilizados nas atividades; na Seção 3 são apresentadas práticas e exercícios realizados referente ao ensino da disciplina de Engenharia de Software, do curso de Ciências da Computação de uma faculdade, além de resultados e dificuldades destas práticas; na Seção 4 são descritas as lições aprendidas destas práticas na disciplina e, por fim, são apresentadas as conclusões. 2 CONCEITOS Vários conceitos são utilizados nas dinâmicas e exercícios ao longo do artigo. Alguns deles vieram do Scrum, como os conceitos de sprint e timebox. Outros, como prototipação, são comuns na literatura de Engenharia de Software.

3 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, Segundo Schwaber (2004), timebox é um período de tempo que não pode ser excedido, no qual um evento ou encontro ocorre. Como exemplo, as standup-meetings (Daily Scrum meeting) possuem um timebox de 15 minutos e terminam ao final desses 15 minutos, obrigatoriamente. Um sprint, conforme Schwaber (2004), é um período (timebox) de 30 dias de calendário sequenciais, durante os quais uma equipe trabalha para tornar o product backlog, selecionado para este período, em um potencial produto entregável. Segundo Sommerville (2008), prototipação é uma versão inicial de um sistema de software, que é utilizada para mostrar conceitos, experimentar opções de projeto, e, em geral, para conhecer mais sobre os problemas e suas possíveis soluções. 3 PRÁTICAS REALIZADAS NO ENSINO DA ENGENHARIA DE SOFTWARE Durante a disciplina de Engenharia de Software do curso de Ciências da Computação da Faculdade Lourenço Filho, localizada em Fortaleza, foram realizadas algumas práticas para repasse de conceitos e técnicas de Engenharia de Software. Nas próximas subseções serão apresentadas como essas práticas foram executadas em sala de aula, pelos alunos, com apoio do professor. 3.1 Ilustração de Fases de Ciclo de Vida Logo no início da disciplina de Engenharia de Software, um dos assuntos tratados é o relacionado a fases e modelos de ciclos de vida. De uma maneira geral, segundo Sommerville (2008), o ciclo de vida de um software envolve as seguintes fases: Especificação (funcionalidade do software e as restrições em sua operação devem ser definidas); Desenvolvimento (produção do software de modo que atenda as suas especificações);

4 24 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 Validação (software deve ser validado para garantir que ele faz o que o cliente deseja); Evolução (software deve evoluir para atender às necessidades mutáveis do cliente). Foi realizado um exercício para ilustrar as fases do ciclo de vida a partir da elaboração de um folder para a propaganda de algum empreendimento. Seus objetivos eram: criar uma sequência de atividades para a construção de um folder, utilizar a sequência de atividades na construção do folder, apresentar a sequência e o folder, e avaliar o resultado. Para isso, os alunos teriam que descrever atividades para especificação, desenvolvimento e validação. Poderiam ser ações, como: identificar necessidades, desenhar logomarca, colar figuras, validar design, etc. O produto seria um folder do tamanho de uma folha A4 para propaganda, e poderia ter um dos seguintes temas: show, peça de teatro, agência de viagem, restaurante, cinema, academia ou evento esportivo. O modelo definido para esse folder pode ser visualizado na Figura 1. Figura 1 Modelo exemplo de folder utilizado no exercício. Os alunos da disciplina foram divididos em quatro equipes de cinco componentes. Naturalmente, algumas equipes se motivam mais que outras, discutindo temas, soluções e dividindo tarefas. Para incentivar o cumprimento da tarefa, as atividades foram divididas em três períodos de tempo: nos primeiros trinta minutos as equipes deveriam ter o tema definido e a

5 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, estrutura do folder; nos próximos trinta minutos, todas as pessoas da equipe já deveriam saber suas atividades e um protótipo deveria ser apresentado, já para uma possível evolução; no restante da aula, as equipes finalizariam seus folders e apresentariam para as outras equipes. Como resultado, algumas equipes não se comprometeram com a tarefa, e construíram um folder muito precário, não respeitando várias regras. Por outro lado, algumas equipes, as mais envolvidas, elaboraram toda uma estratégia para a construção do folder, passando por atividades de especificação, desenvolvimento e validação, apresentando no final um folder que respeitou as regras iniciais e que tinha como características, qualidade e criatividade. 3.2 Modelos de ciclo de vida Outro exercício relacionado a fases foi desenvolvido no decorrer das aulas sobre modelos de ciclos de vida. Durante a disciplina foram discutidos vários modelos, cuja estratégia foi trabalhar o mesmo exercício para cada um dos modelos. O exercício se constituía da elaboração de um cronograma macro, como um gráfico de Gantt ou cronograma de marcos, e um diagrama que representasse o modelo de ciclo de vida, para uma situação hipotética de um ambiente de desenvolvimento de software. Essa situação basicamente era uma descrição de um projeto iniciando na fase de requisitos, seguida pelas fases de análise, projeto, implementação, testes, homologação e implantação, com momentos de validação pelas partes interessadas. Para a disciplina, o exemplo foi: A faculdade deseja automatizar as atividades de matrícula. Para isso, é necessário que as funcionárias da secretaria tenham reuniões para a descrição das funcionalidades, que deverão ser validadas pela diretora. Após o aceite, deve-se passar por uma fase de especificação, que vai da documentação de requisitos, projeto do banco de dados à arquitetura. Só após essa fase é que a implementação será iniciada, seguida de testes locais pelos bolsistas. Depois dos testes, a comissão de avaliação do MEC irá homologar o sistema. Após a aprovação, o sistema finalmente poderá ser implantado.. À medida que os modelos eram apresentados, o mesmo exercício era trabalhado. Quando o modelo foi o cascata, naturalmente o primeiro a ser descrito, os alunos tiveram dificuldade

6 26 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 apenas em entender a sequência de atividades. Quando modelos evolucionários (evolutivo, prototipação e espiral) foram descritos e o exercício foi o mesmo, a reação foi que os alunos ficaram confusos, pois não estavam acostumados a pensar no mesmo exercício sob outra abordagem. A mesma reação foi reduzida quando os modelos incrementais e RAD foram apresentados. Ao final, os próprios alunos chegaram à conclusão de que basicamente os modelos que trabalham iterações teriam o mesmo cronograma e diagrama, e somente o que mudaria seria o foco da abordagem de cada modelo. Uma possível solução seria o cronograma macro e o desenho de um modelo, como pode ser visualizado na Figura 2. Figura 2 Solução para o exercício do modelo de ciclo de vida.

7 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, Práticas do XP (Extreme Programming) Muitas atividades de planejamento, requisitos e qualidade no produto podem ser derivadas de metodologias ágeis. Podem-se realizar várias dinâmicas para exemplificar práticas da metodologia XP. (BECK, 2000). Para isso, foi elaborada uma dinâmica na disciplina baseada em algumas práticas, como: cliente sempre presente, equipe unida, jogo do planejamento, releases curtos. Alguns conceitos e técnicas também foram utilizados, como o de user stories, timebox, marcos ou milestones [Schwaber 2004]. Os alunos deveriam trabalhar essas práticas em cima do desenvolvimento de um projeto de software de um site de previsão do tempo. Como primeiro passo, as equipes foram divididas em no máximo cinco pessoas. O tema do projeto seria o mesmo para todas as equipes. O segundo passo seria a elaboração de user stories para os requisitos do sistema. O professor assumiu o papel do cliente, e as equipes teriam que trabalhar a comunicação, tentar identificar funcionalidades e definir as prioridades do cliente. Após a elaboração das user stories, as equipes teriam que definir a duração de cada iteração, para que pudessem distribuir as funcionalidades ao longo delas, aplicando o conceito de timebox. Cada equipe deveria definir pelo menos dois releases durante as iterações. As funcionalidades eram distribuídas ao longo das iterações, e ao final da aula as equipes apresentavam seus planejamentos. Como principal dificuldade das equipes, deve ser destacada a comunicação com o cliente para a identificação das funcionalidades. Outra dificuldade encontrada foi a distribuição das funcionalidades ao longo das iterações. Esse ponto foi interessante, pois os alunos tiveram que começar a trabalhar a noção de tamanho e complexidade das funcionalidades, para uma melhor distribuição ou divisão das user stories. Como resultado da execução da atividade foi identificada uma série de user stories, suas prioridades, releases e iterações, conforme a Tabela 1.

8 28 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 USER STORIES Tabela 1 Lista de user stories identificadas durante a aula. PRIORIDADE RELEASE ITERAÇÃO Acesso será através da WEB O sistema deverá mostrar a previsão por município, estado e região O sistema deverá mostrar a previsão máxima e mínima O sistema deve fazer a previsão de até 5 dias posteriores, bem como armazenar as previsões de 5 dias anteriores O sistema deve ser capaz de atualizar as previsões a cada 5 minutos O usuário poderá fazer comparações entre as temperaturas da data atual com uma data de anos anteriores O site apresentará imagens ao vivo das capitais Mostrar gráficos O usuário poderá fazer comparações entre as temperaturas de diversas cidades As buscas serão contabilizadas por cidades para que seja criado semanalmente um ranking dos mais buscados O site terá interação com os usuários onde eles poderão informar a situação na sua região O site mostra regiões de risco constante de enchentes O usuário pode dar sugestões sobre o site Haverá uma sessão no site de vídeos, onde estarão vídeos sobre assuntos pertinentes a tempo Mostrar fotos Terá informação sobre acidentes ambientais Dinâmica dos aviões A dinâmica dos aviões é uma prática onde as pessoas têm que construir aviões de papel, seguindo uma linha de produção (uma folha de papel começa numa extremidade da equipe e é trabalhada até se transformar num avião na outra ponta). É como se fosse uma pequena fábrica de aviões. Esta dinâmica é muito utilizada no exercício de metodologias ágeis, onde vários conceitos são aprendidos na prática. Segundo Castro (2009), a ideia da dinâmica é vivenciar os conceitos do SCRUM (SCHWABER, 2004), de forma prática, facilitando a visualização dos

9 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, benefícios. São muito utilizados o conceito PDCA e os processos empíricos, que são algumas das bases dos processos ágeis. Inicialmente foram explicadas para a turma as regras da dinâmica. Algumas adaptações foram realizadas, mas houve um cuidado inicial para que os alunos entendessem como funcionaria a dinâmica. Em seguida, foram formadas as equipes. Como tinham exatamente doze alunos, duas equipes de seis alunos foram formadas. Um aluno de cada equipe foi selecionado para ser o scrum master, outro aluno da equipe foi selecionado para ser o auditor de qualidade, e o restante da equipe faria parte da linha de produção. Quem conduziria todo o processo, e faria também o papel de product owner, seria o professor. Antes de iniciar o processo, as equipes deveriam estimar quantos aviões conseguiriam produzir em uma sprint. Depois das estimativas, o condutor explicou para os alunos algumas informações, correspondente a requisitos do usuário, e solicitou para cada equipe elaborar um protótipo, conforme projetado na Figura 3. Então, novas estimativas deveriam ser realizadas. Cada sprint teve uma duração definida de três minutos. À medida que as sprints finalizavam, um novo planejamento tinha que ser realizado, pois a produtividade da equipe se tornava mais conhecida, e normalmente não era atingida a quantidade estimada de aviões por iteração. Figura 3 Protótipo a ser desenvolvido com especificações do cliente.

10 30 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 Para introduzir uma quebra de ritmo ou tensão, na segunda iteração foi introduzida uma mudança de requisitos, onde a equipe teria que adequar a construção dos aviões. E na terceira sprint, as equipes produziriam os aviões normalmente, sem nenhuma intromissão do condutor. O principal resultado da dinâmica foi à motivação dos alunos na realização das tarefas e a fixação de conceitos básicos, como: timebox, planejamento, prototipação, engenharia, avaliação de qualidade, alteração de requisitos e iterações. Ainda não havia ocorrido uma aula sobre SCRUM, que foi a aula seguinte. Devido à dinâmica, vários conceitos já estavam fixados pelos alunos. Segundo os alunos, realizar o papel do scrum master foi uma grande dificuldade, pois em alguns momentos o aluno responsável não sabia a sequência de atividades que deveria executar no momento para guiar a equipe, em outros, devido à pressão, ele repassava a pressão à linha de produção. O papel do auditor de qualidade foi o que menos executou atividades durante a prática, isto ocorreu porque a estratégia das duas equipes foi verificar os aviões somente no final, permitindo que o auditor perdesse o foco do seu trabalho. O fato de ter sido utilizado um protótipo fez com que a equipe percebesse alguns aspectos funcionais que não estavam claros nas especificações do cliente, fazendo com que ocorressem questionamentos e negociações. A equipe percebeu que em alguns pontos da linha de produção havia a formação de gargalos, fazendo com que algumas pessoas ficassem ociosas. Uma equipe reorganizou a estratégia, utilizando o auditor de qualidade como elemento da linha de produção. As estimativas foram refinadas a cada sprint, conforme indica a Tabela 2. Os replanejamentos ocorreram devido ao melhor conhecimento da produtividade da equipe e a necessidade de se aumentar a produtividade. Tabela 2 Estimativas e valores realizados de cada sprint.

11 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, O gráfico da Figura 4 exibe a evolução das equipes ao longo dos três sprints em relação às estimativas, replanejamentos e o realizado. Ao longo do tempo, as equipes conseguiram equilibrar as estimativas de aviões com sua produção. Figura 4 Gráfico da quantidade de aviões estimada e realizada por sprint. Foram percebidos alguns aspectos comportamentais entre as duas equipes. Após o primeiro sprint, alguns alunos passaram a se comunicar mais, pensando em melhorar a linha de produção. A forma de comunicação utilizada por algumas pessoas nas equipes fez com que outras se engajassem mais, porém em alguns momentos houve situações de inibição devido à forma de se falar. Algumas pessoas ficaram mais preocupadas em verificar o andamento da outra equipe em vez de se ater a sua equipe. Outras utilizaram a tática de tentar sabotar a outra equipe. Ao final dos sprints, quando o condutor foi verificar a quantidade e a qualidade dos aviões, uma equipe também ficou validando os aviões da outra. A Figura 5 mostra como as equipes foram distribuídas na sala de aula, e suas respectivas ações de engenharia e gestão.

12 32 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 Figura 5 Equipes em ação durante a dinâmica dos aviões Fonte: Arquivo da FLF 3.5 NBR ISSO/IEC Uma prática executada com foco no ciclo de vida foi a utilização da norma NBR ISO/IEC (1998). A estrutura desta norma cobre o ciclo de vida do software desde a concepção de ideias até a descontinuação do software. Sua arquitetura é construída com um conjunto de processos e inter-relacionamentos, conforme Figura 6. A atividade consistia na divisão dos processos da norma, conforme um sorteio, para as equipes. As equipes tinham que descrever seus respectivos processos e sua aplicação em conjunto com outro processo sorteado. Além disso, os alunos deveriam também identificar alguma forma de integração com os processos das outras equipes. Os alunos, a princípio, tiveram dificuldade em identificar uma forma de aplicar em conjunto os dois processos sorteados. A intenção era de certa forma forçar o senso crítico e criativo dos alunos, de forma a criarem uma solução de integração entre processos diferentes. Às vezes, conforme o sorteio, os processos eram bem diferentes, mas a ideia era que os alunos identificassem algum ponto de integração. Quando cada equipe apresentava seus resultados, as

13 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, outras equipes começavam a questionar as formas de integração e também sugeriram outras formas. Por exemplo: foram sorteados o processo fundamental de manutenção e o processo de apoio de validação. Uma maneira de integrá-los seria definir uma forma de validar as atividades de manutenção, como validar a implementação da modificação através de testes de uma equipe de testes ou cliente, para determinar se os requisitos e o produto final atenderiam à proposta inicial. Figura 6 Processos de ciclo de vida da norma ISO/IEC LIÇÕES APRENDIDAS De maneira geral, muitos conceitos foram aprendidos e exercitados através das práticas e dinâmicas. Como geralmente as práticas envolviam aspectos comportamentais, devido aos diversos perfis envolvidos em Engenharia de Software, muitos alunos tiveram reações semelhantes às encontradas em ambientes reais de desenvolvimento.

14 34 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 Um ponto forte foi o planejamento de todas as dinâmicas pelo professor, o que permitiu uma melhor organização e desenvolvimento mais fácil das dinâmicas. Outro ponto importante foi a motivação identificada na maioria dos alunos, pois normalmente não são aplicados em sala exercícios mais dinâmicos ou que simulem situações práticas. 5 CONCLUSÃO A aplicação de exercícios sobre assuntos teóricos com práticas mais interativas é uma forma de se fixar conceitos e disciplinas da Engenharia de Software. Diversos assuntos podem ser trabalhados, como modelos de ciclo de vida e práticas ágeis, e sempre as reações e retornos dos alunos irão refinar essas dinâmicas. Como o professor também é analista de sistemas em uma empresa de desenvolvimento de software, isso facilitou no ensino da disciplina, tanto pela troca de experiências como através de situações reais. Como a ideia inicial desses exercícios foi que os alunos assimilassem os conceitos, este objetivo foi atingido. A vivência e a experiência possibilitaram uma visão mais real, do ponto de vista de planejamento, adequação às mudanças e comunicação dentro da equipe. Do ponto de vista do ensino em Engenharia de Software, o ideal é que novas dinâmicas sejam criadas e aplicadas nos diversos assuntos, pois foi comprovado que os alunos aceitam tais práticas e, assim, entendem melhor os conceitos. Application of Concepts and Techniques in the Teaching of Software Engineering ABSTRACT Currently, traditional teaching techniques and concepts of software engineering has not been very effective in learning due to lack of proximity to the theory forwarded to the practice applied in developing systems. The diversification of teaching techniques has a number of benefits to students as they assimilate the concepts better. In this context, this paper presents the application of techniques and concepts of Software Engineering in the classroom in order to approach the implementation of practices in teaching

15 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, with the actual application software development. Also presents an analysis of results and student feedback regarding the implementation of techniques and concepts. Keywords: Software Engineering, Concepts. REFERÊNCIAS AGUIAR, Y. P. C., LIMA, A. H. G., LEITE, F. L. J., EasYProcess: Um Processo de Desenvolvimento para Uso no Ambiente Acadêmico. In: XII Workshop de Educação em Informática - XXIV Congresso da Sociedade Brasileira de Computação, Salvador, ANDRADE, R. M. C., MARINHO, F. G., LEITÃO, V. L., ROCHA, L. S., Uma Proposta de Metodologia para o Ensino de Engenharia de Software, FEES2008, Fórum de Educação em Engenharia de Software, BECK, K., Extreme Programming Explained, Addison-Wesley Publishing Co, CASTRO, F. S., Dinâmica Fábrica de Aviões 2.0, LUCENA, V. F. J, BRITO, A., JAZDI, N., Uma Metodologia Germano-brasileira para o Ensino de Engenharia de Software para Alunos de Engenharia Elétrica, XXXIV COBENGE - Congresso Brasileiro de Ensino de Engenharia. Passo Fundo, NBR ISO (1998), NBR ISO Tecnologia de Informação Processos de ciclo de vida de software, Associação Brasileira de Normas Técnicas ABNT. Rio de Janeiro. PRIKLADNICKI, R., ALBUQUERQUE, A. B., WANGENHEIM, C. G., CABRAL, R., Ensino de Engenharia de Software: Desafios, Estratégias de Ensino e Lições Aprendidas, FEES 2009, Fórum de Educação em Engenharia de Software, SCHWABER, K., Agile Project Management with Scrum, ISBN: x, Microsoft Press, SCHNEIDER, J., JOHNSTON L., Extreme Programming at Universities An Educational Perspective, Proceedings of the 25th International Conference on Software Engineering, Portland, Oregon, pp , SILVA, L. F., LEITE, J. C., BREITMAN, K. K., Ensino de Engenharia de Software: Relato de Experiências, XII WEI - Workshop de Educação em Informática (XXIV SBC), SOARES, M. S., Uma Experiência de Ensino de Engenharia de Software Orientada a Trabalhos Práticos, XXIV Congresso do SBC, XII WEI - Workshop de Educação em Computação, SOMMERVILLE, I., Engenharia de Software, 8 a ed., São Paulo. Pearson, 2008.

16 36 Revista Científica da Faculdade Lourenço Filho - v.7, n.1, 2010 STEVENS, K. T., Experiences Teaching Software Engineering for the First Time, Proceedings of the 6th annual conference on Innovation and technology in computer science education, Canterbury, United Kingdom, pp 77-80, TOMAYKO, J. E., Teaching a Project-Intensive Introduction to Software Engineering, Carnegie Mellon University, Software Engineering Institute, CMU/SEI-87-TR-20, Emanuel Ferreira Coutinho Professor do Instituto UFC Virtual MBA em Gerência de Projetos, UFRJ Mestre em Ciência da Computação, UECE emanuel@virtual.ufc.br Carla Ilane Moreira bezerra Professora do Curso de Engenharia de Software, UFC Quixadá Mestre em Ciência da Computação, UNIFOR carlailane@ufc.br