Engenharia de Software

Published:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

RESUMO

A engenharia de software tem ganhado uma posição de destaque na computação e nas indústrias de software. É composto por diversas áreas de conhecimento como engenharia de requisitos, conção e mudanças, qualidade, processos de desenvolvimento, dentre outros. Entretanto, o estudo dessas disciplinas é tratado de forma isolada e teórica, não obtendo grandes interesses de estudo por parte dos alunos. Este projeto vem apresentando aspectos teóricos e oferecendo uma experiência prática da aplicação conceitos da Engenharia de Software, através de uma metodologia de ensino apoiado por um framework adaptável às necessidades do ensino. Nesta experiência é adotada uma filosofia de desenvolvimento cooperativa do RUP.

Palavras-chave:

Engenharia de Software, Ensino, Framework, Customização de Processos de Software.

1. INTRODUÇÃO

A prática da engenharia de software vem ganhando destaque no mercado. Visando o aumento da qualidade do software produzido, a indústria de software tem incorporado métodos e técnicas de Engenharia de Software, otimizando o desenvolvimento com qualidade, alta produtividade e respeitando os prazos previstos (CAROSIA; NAKANISHI, 2003). Com teorias, métodos e ferramentas nas situações apropriadas, de acordo com os problemas a serem resolvidos, restrições e recursos disponíveis (SOMMERVILLE, 2003). A qualidade dos produtos esta diretamente ligada à qualidade de seu processo, na política, estrutura organizacional, procedimentos e produtos de trabalhos.

O processo de ensino e aprendizagem de Engenharia de Software tem passado por questionamentos (HILBUM; TOWHIDNEJAD, 2007). Ao longo dos anos a Engenharia de Software vem colocando novas abordagens e técnicas visando melhoria e integração entre disciplinas. Mas as instituições de ensino ainda se limitam ao ensino de conceitos e fundamentos da Engenharia de Software através de disciplinas teóricas, com aulas expositivas e textos complementares, com a prática limitando a pequenos projetos em um pequeno espaço de tempo (HUANG; DISTANTE, 2006).

1.1. O PROBLEMA E SUA IMPORTÂNCIA

A pesquisa de Duarte, Pivatto, demonstrou que existem conhecimento adquirido na disciplina de Engenharia de Software, no entanto, muitos acadêmicos após cursarem a disciplina não possuem um conhecimento satisfatório.

A permanente renovação dos conhecimentos é extremamente necessária, Piaget, propõe que o que caracteriza a aprendizagem é o movimento de um saber fazer a um saber (PIAGET, 1975). O professor deve ser responsável por elaborar a metodologia planejada e adequada, construtiva, agrupando teorias modernas de aprendizagem.

Muitos estudos e pesquisas estão sendo realizados para a melhoria do ensino da Engenharia de Software, aplicando técnicas que focam principalmente a prática dos conteúdos. Inclusive artifício que tem provido bons resultados são simulações de ambientes indústrias de desenvolvimento e jogos simuladores, conforme citados no tópico “Trabalhos relacionados”.

1.2. OBJETIVO

1.2.1. Objetivo geral

Propor um framework adaptável para ensino de Engenharia de Software em cursos de graduação.

1.2.2. Objetivos específicos

* Propor um processo de software adaptável às necessidades de ensino de Engenharia de Software.

* Estabelecer o fluxo das atividades.

* Definir a metodologia para a aplicação do processo.

* Definir um conjunto de produtos de trabalho para a utilização do processo.

2. REFERENCIAL TEÓRICO

2.1. ENGENHARIA DE SOFTWARE

A Engenharia de Software é uma disciplina que aborda todos os estágios da produção do software, desde a especificação à manutenção pós-entrega, não se dedicando apenas aos processos técnicos de desenvolvimento, mas também a atividades gerenciais, ferramentas, métodos e teorias que apóiam à produção de software (SOMMERVILLE, 2003).

A disciplina de Engenharia de Software tende a transmitir para o aluno uma visão dos processos de desenvolvimento de software, o capacitando para traduzir problemas para sistemas (UFPA, 2009), através do estudo os conceitos e processos, preocupando sistematicamente com o desenvolvimento através de modelos, técnicas e ferramentas para os produtos de trabalho e o processo (UFRN, 2009).

2.2. CONCEITOS

2.2.1. Fases

As fases indicam a ênfase dada em um determinado instante do projeto, são compostos por iterações é geram artefatos.

No RUP o ciclo de vida do software possui quatro marcos seqüenciais principais, o intervalo de tempo entre um marco e outro são considerados fases. As fases são executadas seqüencialmente: iniciação, elaboração, construção de transição. Ao término de cada fase é realizada uma avaliação para avaliar a eficiência alcançada. Na conclusão da última fase é obtida uma nova geração do software (WTHREEX, 2009).

O OpenUp possui suas fazes constituído das mesmas bases do RUP: Concepção, Elaboração, Construção, e Transição. Cada fase pode ter uma ou mais iterações conforme forem necessárias. Ao fim de cada iteração é alcançado um marco, onde os objetivos da fase são alcançados. (OPENUP BASIC, 2009).

2.2.2. Disciplinas

Consiste em um resumo dos papeis, atividades para obter um conjunto de artefatos. Descrito de forma generalizada, assimila os tópicos envolvidos (WTHREEX, 2009). Contemplam um conjunto de tarefas tendentes a uma área de interesse comum em suas preocupações e esforços.

2.2.2.1. Papéis e Atividades

Papeis são comportamentos empenhados por indivíduos para realizar uma atividade perante suas responsabilidades, não sendo especificamente uma pessoa, pode ser uma equipe, ou em contrapondo uma pessoa pode exerce diversos papeis (WTHREEX, 2009). Os papeis exercem atividades que são funcionalmente combinadas. Através das atividades são desenvolvidos produtos de trabalho que são utilizados para colaborar mutuamente entre as atividades, tendo as informações transmitidas em um canal comum.

A política não determina quais pessoas desempenharão quais papeis, os papeis a serem desempenhados é definido na política de Gerência de Conção de Software.

2.2.2.2. Artefatos

Produtos de trabalho podem ser intermediários ou finais, sendo produzidos, modificados e utilizados no desenvolvimento do projeto de software. São utilizados dentro do ciclo de vida do software para transmitir informações entre as atividades, e ou mesmo servir de matéria prima para execução de outra atividade a fim de gerar novos produtos. Podendo ser como exemplo documentos e modelos. (WTHREEX, 2009)

2.2.3. Iterações

As iterações têm como objetivo a entrega de resultados de valores, tendo a cada termino de iteração a entrega de uma versão do software, já implementado e testado. Assim, tendo a passagem por todas as disciplinas (WTHREEX, 2009). A duração de cada interação varia conforme o tamanho e a natureza do projeto.

2.3. PROCESSOS DE SOFTWARE

Consistem em um conjunto de métodos, práticas, papeis e atividades parcialmente ordenados, aplicáveis a qualquer projeto de software independente de seu tamanho ou complexidade, para desenvolvimento ou evolução do software. (SOMMERVILLE, 2003).

O processo de software aplicado em sua definição e normatização é um dos principais mecanismos para se obter software de qualidade. A automatização do processo de Software através de ferramentas Case tem se tornado cada vez mais extensiva, mas ainda muito limitada, já que há uma enorme dependência do julgamento de criatividade humana no processo (SOMMERVILLE, 2003). Apresenta as seguintes fases:

2.3.1. Especificação do Software

Também conhecida com engenharia de requisitos, essa fase é importante para evitar erros futuros no projeto. O processo resulta na elaboração do documento requisitos ou mesmo no documento de especificação do sistema (SOMMERVILLE, 2003).

A engenharia de requisitos pode ainda ser divida em quatro fases, mas não necessariamente sendo seguido rigorosamente, como exemplo, os requisitos podem ser alterados e incluídos ao longo de todo o processo (SOMMERVILLE, 2003):

* Estudo de viabilidade: Analisa a viabilidade do requisito do ponto de vista comercial e orçamentária.

* Levantamento e análise de requisitos: Parte para coleta e análise detalhada do requisito considerando o sistema existente, podendo utilizar modelos, protótipos e técnicas de Entrevista.

* Especificação do requisito: Fase de transcrição do requisito coletado para o formato de requisito, incluindo atributos adicionais como casos de uso.

* Validação de requisito: Processo em que é verificada a consistência, integridade e pertinência

2.3.2. Desenvolvimento do Software

Um processo dinâmico de melhoria, que implica uma mudança, evolução, crescimento e avanço. Consiste pelo menos em sua maior proporção na transferência dos requisitos do projeto para código, resultando em componentes do produto, transformando as necessidades de um usuário ou de um mercado em um produto de software (SOMMERVILLE, 2003)..

Durante a implementação do software são encontrados erros e irregularidades, sendo assim importante haver feedback's no processo para a melhoria e correções (SOMMERVILLE, 2003).

2.3.3. Validação do Software

Destina-se a verificação e validação do software, para constatar se produto desenvolvido está de acordo com as especificações e se irão atender as expectativas do cliente. Esse processo é mais utilizado depois da implementação, mas é importante fazer uso em todas as etapas, desde a definição dos requisitos junto ao usuário até o desenvolvimento do software (SOMMERVILLE, 2003).

2.3.4. Evolução do Software

Também descrito como manutenção de software, é o processo de alterações efetuadas no software após a entrega. Normalmente são atividades de relevância menores que o projeto inicial, mas com custo superior (SOMMERVILLE, 2003).

Existem diversos modelos de processos, que organiza e classificação em diversas maneiras. Alguns processos podem ser mais adequados de acordo com o tipo de aplicação, resultando na qualidade do software a ser desenvolvido (SOMMERVILLE, 2003).

2.4. MODELOS DE PROCESSO DE SOFTWARE

Representação do processo de software de uma forma simplificada e abstrata do processo e sua dinâmica, apresentado a partir de uma perspectiva específica. A seguir, comenta-se sobre alguns modelos de processos genéricos, abstrações não definitivas do processo, mas que servem para diferentes abordagens (SOMMERVILLE, 2003).

2.4.1. PROCESSOS UNIFICADO (UP)

Conjunto de atividades que combina os modelos de processo iterativo e incremental, com a construção baseando não apenas em documentação, mas principalmente nos artefatos do software (POMBAL; RIBEIRO; CARNEIRO).

Tem objetivo de produzir software de qualidade empregando as teorias da Engenharia de Software de forma unificada (POMBAL; RIBEIRO; CARNEIRO).

Possui o ciclo de vida composto por quatro fases: Concepção, elaboração, construção e transição. A cada ciclo trilhado é alcançado uma nova “geração” do software (POMBAL; RIBEIRO; CARNEIRO).

2.4.2. RATIONAL UNIFIELD PROCESS (RUP)

Metodologia criada pela Rational, sendo um modelo proprietário comercial que possui uma extensa documentação fornecendo técnicas para viabilizar sucesso dos projetos de software (WTHREEX, 2009).

O RUP expõe diversos modelos de produtos de trabalho, assim como a descrição em detalhas tarefas que o geram. É um modelo muito extensivo, sendo a customização uma solução para adaptar aos diversos projetos (WTHREEX, 2009).

A 1 demonstra aspectos do ciclo de vida da metodologia de processo do RUP. No eixo horizontal é apresentado o tempo à medida que se desenvolve, no eixo vertical estão às disciplinas. Assim é possível analisar o empenho do tempo e disciplinas em cada fase do projeto.

2.4.3. OPENUP

O OpenUp é um processo iterativo, mínimo, completo e extensível. Agrega muitos conceitos do RUP e adiciona valores e práticas ágeis principalmente de metodologias como do XP e o Scrum. É governado por quatro princípiosbásicos (OPENUP, 2009).:

· Balancear as prioridades competitivas para maximizar o valor aos Stakeholders.

· Colaborar para alinhar os interesses e compartilhar conhecimentos.

· Evoluir para continuamente obter feedback e promover melhorias.

· Focar na articulação da arquitetura.

Segundo José Papo (PAPO, 2009) os esforços de cada membro da equipe é dividido em micro-incrementos, que são pequenas quantidades de trabalho que fazem parte do progresso do projeto. Especificados com item de trabalho (work item), que deve ser bem definidos para haver o monitoramento e controle diário do processo.

Os itens de trabalho são muito valorizados, pois sua em pregação asseguram um processo contínuo, e utilizando técnicas de reuniões diárias e ferramenta de colaboração para conseguir transparência no trabalho (PAPO, 2009).

Suas iterações têm como objetivo a entrega de resultados de valores aos clientes por parte da equipe, a cada pequeno ciclo de tempo, geralmente de algumas semanas. A cada termino de iteração a equipe entregar um versão do software, já implementado e testado (PAPO, 2009).

O monitoramento do progresso de cada iteração é baseado nos itens de trabalho, assim como o planejamento e estimativa. Cada membro da equipe possui autonomia para tomar decisões em suas colaborações no projeto. Para a auto-organização funcionar é imprescindível que os colaboradores tenham uma comunicação aberta e transparência e compromisso. O gerente de projeto atua mais como líder educador, deixando de lado a idéia de chefe (PAPO, 2009).

2.5. ADAPTAÇÃO DE PROCESSOS DE SOFTWARE (CUSTOMIZAÇÃO)

É a reutilização do processo de software já existente, buscando maior aceitação e otimização do uso do processo de software (MAIA, FREITAS, NUNES, 2004).

A eficiência de um processo pode variar não apenas de organização para organização, mas também em diferentes projetos. Atualmente existem diversos modelos de processo disponíveis, mas nenhum que se adéqüe a todas as situações, assim, uma solução é a customização do modelo definido pela organização através de diretrizes e critérios (COELHO, 2003).

A adaptação de frameworks de processo busca englobar todos os elementos que possam ser úteis a qualquer tipo de projeto, tais como artefatos, atividades. Possui por filosofia expor um processo mais abrangente, retirando elementos não usáveis em situações específicas (COELHO, 2003).

2.6. SOFTWARE PROCESS ENGINEERING METAMODEL (SPEM)

Metamodelo usado na Engenharia de Software para especificar e modelar processos do software baseando principalmente na UML. Seu objetivo principal é documentas e comunicar o processo, com idéia de constante e evolução e melhoria do processo.

2.7. FRAMEWORK

Consiste em modelo de dados, contendo conceitos para soluções de problemas de um domínio. Compreendendo em uma abstração do contexto geral, expondo o modo de iteração entre as instâncias (COELHO, 2003).

* Um exemplo de framework é o RUP, que trás uma metodologia de processo documentado com a utilização de UML.

2.8. ECLIPSE PROCESS FRAMEWORK COMPOSER

Para a representação do processo em forma de portal será utilizado o Eclipse Process Framework Composer (EPF), que auxilia na criação e descrição de processos de desenvolvimento de Software, com conceitos de disciplinas, de Engenharia de Software, ciclo de desenvolvimento, iteração, papeis, tarefas e descrição de como deve ser feito. Através da publicação do processo descrito no EPF e gerado um portal para visualização através do Browser (EPF, 2009).

3. TRABALHOS RELACIONADOS

Muitas pesquisas estão sendo efetuas para melhorar o ensino da Engenharia de Software. Algumas pesquisas são importantes comentar:

Segundo Silva, Leite e Breitman (2004), em seu trabalho “Ensino de Engenharia de Software: Relato de Experiências”; a experiência adquirida com um método de ensino aplicado à disciplina de Engenharia de Software pela PUC - Rio aos alunos de Engenharia de Computação. O método visa despertar interesse dos alunos, apresentando os aspectos teóricos e oferecer uma experiência prática da aplicação destes dos conceitos, adotando uma filosofia de desenvolvimento cooperativo, com o processo Extreme Programming (XP). Conforme a conclusão dos autores a teoria é dificilmente absorvida pelos alunos se não utilizado a prática. A utilização de trabalhos com grandes equipes simulando o cenário real, com tantos problemas como falta de comunicação, gerenciamento faz com que o aluno estude diversas áreas de engenharia de software de forma mais prática e satisfatória.

Barros, Araujo (2008) com o tema “Ensinando Construção de Software Aplicada a Sistemas de Informação do Mundo Real” apresentam um estudo de caso realizado durante um curso de construção de software no Mestrado de Sistemas de Informação do PPGI/UNIRIO. No curso os alunos foram designados a desenvolver conjunto de requisitos funcionais, submetendo-se a mudanças e respondendo como do mundo real, aproximando da situação industrial. A expectativa era que os alunos compreendessem o valor de prever mudanças futuras e evitar efeitos colaterais das mudanças sofridas pelo software. Em entrevista efetuada ao final do curso com os alunos, os objetivos foram alcançados.

Santos, et al. (2007) no trabalho: “Integrando as Disciplinas de Engenharia de Software, Análise e Projeto de Sistemas e Banco de Dados utilizando PBL” expõem os problemas atuais do ensino atual da engenharia de software e relata o estudo integrado de Engenharia de Software, Análise e Projeto de Sistemas e Banco de Dados, adotando PBL (Project-Based Learning) como metodologia prática de ensino. Com a aplicação da metodologia em uma turma, consegue-se passar para os alunos de uma maneira mais fácil a integração das disciplinas, alem de poder aplicar na prática os conceitos.

Andrade, et al. (2008) através do trabalho: “Uma Proposta de Metodologia para o Ensino de Engenharia de Software” cita os problemas atuais do ensino de Engenharia de Software, principalmente a falta da prática na disciplina por limitação da carga horária. No trabalho é apresentado uma metodologia de ensino teórico-prática adotada na disciplina de ES da UFC que consiste em um paralelo no ensino teórico e o desenvolvimento de um projeto de software. Espera-se facilitar o entendimento dos conceitos teóricos e melhorar o desempenho dos alunos.

Santos, et al. (2008) em seu trabalho “Usando PBL na Qualificação de Profissionais em Engenharia de Software” apresentam uma metodologia de ensino baseada em PBL (aprendizagem baseada em problemas) que possui objetivo de aprimorar o aprendizado em Engenharia de Software, promovendo a habilidade de resolver problemas em ambientes de fábricas de software. A metodologia tem sido aplicada no Mestrado Profissional em Engenharia de Software, desde 2007.

O uso demonstrou um crescimento no desempenho, analisado de 0 (zero) a 10 (dez), uma redução da diferença da menor para a maior nota o rendimento de 3,58 para 0,83 dos estudantes.

Figueiredo, et al. (2007) em seu trabalho “Um Jogo para o Ensino de Engenharia de Software Centrado na Perspectiva de Evolução”, apresenta o SimulES, um jogo de cartas que simula o processo de desenvolvimento de software. O jogo coloca o jogador como gerente de projeto, deparando com problemas que não são bem cobertos em aulas tradicionais.

4. DESENVOLVIMENTO

Inicialmente foi efetuado levantamento das ementas dos cursos de ciência da computação e sistema de informação de diversas instituições de ensino superior do país, através dos sites das instituições e busca pelo Google. Sendo então gerada uma matriz para mapear os conceitos lecionados nas instituições. Para assim, conhecer o que é ensinado em Engenharia de Software, e idealizar o formado da customização a ser utilizada no projeto, resultando no quadro abaixo.

Quadro2 - Relação das disciplinas com os lecionamentos das instituições.

Área

Conteúdo

Instituições

1

2

3

4

5

6

7

8

9

10

Introdução

X

X

X

X

X

X

X

X

História da engenharia de software

X

Aspectos éticos

X

Engenharia de sistema com base em computadores

X

X

Processo de Software

X

X

X

X

Modelo de processo de software

X

X

X

Iteração de processo

X

Especificação de software

Projeto e implementação de software

X

Validação de software

Evolução de software

Apoio ao processo automatizado

Gerenciamento de Projetos

X

X

X

X

X

X

X

X

X

X

Atividades de gerenciamento

Planejamento de projeto

X

X

X

Programação de projeto

Gerenciamento de risco

Requisitos de Software

X

X

X

X

Requisitos funcionais

Requisitos não funcionais

Requisitos de usuário

Requisitos de sistema

Processo de Engenharia de Requisitos

X

X

X

X

X

X

Estudos de viabilidade

Obtenção e análise de requisitos

X

X

X

X

Validação de requisitos

X

Gerenciamentos de requisitos

Modelos de Sistema

X

X

X

X

Modelos de contexto

Modelos de comportamento

Modelos de dados

Modelos de objeto

X

Prototipagem de Software

X

X

X

Prototipação

X

X

Técnicas de Prototipação

Prototipação de interface com usuário

X

X

Especificação de Software

X

X

X

Especificação formal

X

X

X

Especificação de interface

Especificação de comportamento

Projeto de Arquitetura

X

X

X

Estruturação do sistema

Modelos de controle

Decomposição em módulos

X

Arquiteturas de domínio específico

Verificação de Validação

X

X

X

X

X

Planejamento de verificação e validação

X

X

Inspeções de software

X

Análise estática automatizada

Teste de Software

X

X

X

X

X

X

Testes para a detecção de defeitos

Testes de integração

Testes orientados a objetos

Bancadas de testes

Estimativa de Custo de Software

X

X

Produtividade

Técnicas de estimativa

X

Modelagem algorítmica de custo

Duração de projeto e pessoal

Gerenciamento de Qualidade

X

X

X

X

X

X

Garantia e padrões de qualidade

X

Planejamento de qualidade

Controle de qualidade

Medição e métricas de software

Melhoria de Processo

X

Qualidade de processo e de produto

Modelagem e análise de processo

Medições de processo

Modelo de Maturidade de capacitação de SEI

Classificação de processo

Mudança de Software

X

X

X

X

X

X

X

Dinâmica da evolução de programas

Manutenção de software

X

X

X

Evolução de arquitetura

X

Reengenharia de Software

X

Tradução de código-fonte

Engenharia reserva

X

Melhoria de estrutura de programa

Gerencia de Conção

X

X

X

X

Planejamento de gerenciamento de config.

Gerenciamento de mudanças

Gerenciamento de versões e releases

Construção de sistemas

Ferramentas CASE para gerenciamento

X

X

X

X

Desenvolvimento Ágil

X

Legenda:

1-Faculdade de Balsas - Unibalsas

2-Faculdade de Ciências Sociais e Tecnológicas - FACITEC

3-Universidade Estadual de Londrina - UEL

4-Universidade Federal do ABC - UFABC

5-Universidade Federal de Goiás - UFG

6-Universidade Federal de São Carlos - UFSCAR

7-Universidade Federal de Viçosa - UFV

8-Universidade Estadual de Maringá - UEM

9-Universidade Federal do Pará - UFPA

10-Universidade Federal do Rio Grande do Norte - UFRN.

Fontes: (UNIBALSAS, 2009); (FACITEC, 2009); (EUL, 2009); (UFABC, 2009); (UFG, 2009); (UFSCAR, 2009); (UFV, 2009); (UEM, 2009); (UFPA, 2009); (UFRN, 2009).

A partir dos dados das ementas, foi então efetuado estudo dos conteúdos que são adotados, para assim, conhecer em detalhes o conteúdo e analisar que tipo de avaliação em equipe ou individual (trabalho) pode ser aplicável para cobrir o conteúdo identificado. Assim como os produtos de trabalho gerados pela utilização dos conteúdos, pois fazem parte do método de aplicação, dando ao professor ponto de visualização da evolução ou dificuldade do aluno.

Ouve uma grande semelhança entre o os conteúdos de lecionados pelas universidades brasileiras quanto o processo e produtos de trabalho do OpenUp, alem de ser um framework aberto não proprietário. Assim, o tomaremos como alvo de nosso experimento para a customização do processo.

Para a representação e descrição do processo em forma de portal será utilizado o Eclipse Process Framework Composer, tomando com base processo já definido e de trabalho OpenUp.

Com o uso do EPF Composer são gerados arquivos XMI que contem todos do projeto criado, com esses arquivos o software desenvolvido ira trabalhar, com adaptação através de uma matriz de conção do processo, para que o processo possa ser aplicado, ou adaptado.

4.1. SOFTWARE PARA CUSTOMIZAÇÃO DO PROCESSO (XPROCESS)

Para implementar o software de customização foi utilizada a linguagem de programa Pascal, no ambiente de desenvolvimento Delphi 2007.

4.1.1. Visão Geral

O Software tem por finalidade de customização de processos gerados pelo Eclipse Process Framework Composer, tendo como entrada os arquivos XMI gerados pelo EPF Composer, e saída os mesmos arquivos XMI para serem utilizados pelo EPF Composer porem customizados pelo usuário.

Com o EPF Composer o usuário poderá efetuar a publicação do processo, resultando na geração da apresentação dos elementos do processo em forma de portal, seguindo o padrão SPEM.

4.1.2. Perspectivas

Facilitar para o usuário a geração de processos de construção de Software, baseado em processos já existentes tomados como referência, assim como os disponibilizados pelo Eclipse Foundation: OpenUp, XP, Scrum, que serão alvos do estudo de caso deste documento

4.1.3. Funções

* Lançar disciplinas que serão trabalhadas.

* Mapear as disciplinas para o processo designado do projeto EPF Composer.

* Efetuar customização do processo.

* Exportar as alterações para o projeto do EPF Composer.

Possui por finalidade habilitar ou desabilitar os processos e produtos de trabalho utilizados no processo alvo, através da alteração dos arquivos xmi de conção do projeto do EPF Composer.

4.1.4. Limitações

O Software e dependente as informações geradas pelo EPF Composer, e a customização efetuado pelo Software depende da publicação do EPF Composer para geração do portal.

4.1.7. Estudo de Caso

Para o estudo de caso foi utilizado para a adaptação uma publicação do OpenUp disponibilizado pela Eclipse Foundation em “http://www.eclipse.org/downloads/download.php?file=/technology/epf/OpenUP/published/OpenUP_published_PT-1.0-20070801.zip”.

A tela principal do Software já descreve para o usuário o processo que será tomado do inicio ao fim para efetuar a customização do processo. Dadas pela seqüência: “Cadastrar Conteúdo Lecionado”, “Selecionar o Processo do EPF”, “Mapear Conteúdo para o Processo”, “Adaptar o Processo” (Através da Matriz), e “Exportar a Adaptação para o EPF”.

O seguinte passo é a adaptação, onde o usuário seleciona na treeview lateral esquerdo as disciplinas e processos desejados para serem utilizados, os que ficarem desmarcados serão desconsiderados. Na treeview lateral direita o usuário ainda pode detalhar a customização dentro dos processos/conteúdo selecionado na treeview lateral esquerda, dando-o ao usuário maior versatilidade para customização desejada.

5. CONCLUSÃO

Com o auxilio do Software o usuário/educador consegue a partir de um processo base com o OpenUp utilizado no estudo de caso, adaptá-lo para seu público de interesse com sucesso, podem quer reaproveitamentos do projeto original. Assim como no caso de uso que não seria interessante o processo de “concordar com a abordagem técnica” e foi retirado.

Não necessário o usuário precisa trabalhar com os frameworks disponíveis como OpenUp, Scrum e outros, pode esta criando seus próprios frameworks e para a aplicação customiza-lo da forma mais interessante para o momento.

REFERÊNCIAS BIBLIOGRÁFICAS

ANDRADE, R. M. de C.; MARINHO, F. G.; LEITÃO, V. L.; ROCHA, L. S. Uma Proposta de Metodologia para o Ensino de Engenharia de Software. In Anais do XXIV Workshop sobre Educação em Computação, Campinas, 2008. CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO. Departamento de Computação - Universidade Federal do Ceará (UFC)

BARROS, M. de O.; ARAUJO, R. M. de A. Ensinando Construção de Software Aplicada a Sistemas de Informação do Mundo Real. In Anais do XXIV Workshop sobre Educação em Computação, Campinas, 2008. CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO.Programa de Pós-Graduação em Informática, UNIRIO; Núcleo de Pesquisa e Prática em Tecnologia, UNIRIO.

CAROSIA, J. S. Levantamento da qualidade do processo de software com foco em pequenas organizações. Instituto Nacional de Pesquisas Espaciais -INPE. Dissertação de Mestrado do Curso da Pós-Graduação em Computação Aplicada. 30 de Setembro de 2003.

COELHO, Ciro Carneiro. MAPS: Um Modelo de Adaptação de Processo de Software. Universidade Federal de Pernambuco, Recife, 2003

FIGUEIREDO, E. F.; LOBATO, C.; DIAS, K.; LEITES, J.; LUCENA, C. L. Um Jogo para o Ensino de Engenharia de Software Centrado na Perspectiva de Evolução. In Anais do XXIV Workshop sobre Educação em Computação, CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO. Rio de Janeiro, 2007. PUC - Rio, Rio de Janeiro, Brasil.

HUANG, S.; DISTANTE, D. On Practice-Oriented Software Engineering Education. In: Conference on Software Engineering Education & Training WORKSHOPS - CSEETW '06, 19., 2006, Turtle Bay. Proceedings … Washington: IEEE Computer Society, 2006.

MAIA, Anderson Baia; FREITAS, Ana V. Piaggio; NUNES, Daltro José. Um Modelo para Auxiliar a Adaptação de Processos de Software. IV Congresso Brasileiro de Computação - CBComp, 2004.

PIAGET, J. Psicologia e Pedagogia. Rio de Janeiro: Forense-Universitária, 1975. 3ª edição.

POMBAL, A. A.; RIBEIRO, J. P.; CARNEIRO, J. M. G.. O Processo Unificado de Desenvolvimento de Software.

SANTOS, D. M. B.; SABA, H.; JUNIOR, J. R.; SARINHO, V. Integrando as Disciplinas de Engenharia de Software, Análise e Projeto de Sistemas e Banco de Dados utilizando PBL. In Anais do XXIV Workshop sobre Educação em Computação, Rio de Janeiro, 2007. CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO. Departamento de Ciências Exatas - Universidade Estadual de Feira de Santana (UEFS)

SILVA, L. F., LEITE, J. C. S. P. e BREITMAN, K. K. (2004). Ensino de Engenharia de Software: Relato de Experiências. In Anais do XXIV Workshop sobre Educação em Computação, Salvador, SBC, 12p.

SOMMERVILE, Ian. Engenharia de Software. 6. ed. São Paulo: Pearson Education, 2003.

PAPO, José. OpenUp: Uma Introdução. Visão Ágil. Brasil. Edição 01, Ano II. Páginas 25 a 28. 2009.

EPF - Eclipse Process Framework Project (EPF). Disponível em: <http://www.eclipse.org/epf/> Acessado em: 19 de outubro de 2009.

OPENUP BASIC - Roteiro OpenUp/Basic. Disponível em: <http://epf.eclipse.org/wikis/openuppt/openup_basic/guidances/roadmaps/openup_basic_roadmap,_vEruwN-rEdqiM_wFaqLjNg.html> Acessado em 15 de outubro de 2009

WTHREEX - Rational Unified Process. Disponível em: <http://www.wthreex.com/rup/portugues> Acesso em: 22 de maio de 2009.

Faculdade de Balsas - Unibalsas. Ementa do curso. Disponível em: <http://www.unibalsas.edu.br/index.php?option=com_content&view=article&id=94&Itemid=84> Acesso em: 27 de maio de 2009.

Faculdade de Ciências Sociais e Tecnológicas - FACITEC. Ementa do curso. Disponível em: <http://www.facitec.br/downloads_arquivos/planos_ensino_2007/bsi/6/engenharia_de_software.pdf> Acesso em: 27 de maio de 2009.

Universidade Estadual de Londrina - UEL. Ementa do curso. Disponível em: <http://www.uel.br/pos/cienciacomputacao/?content=ementa.htm> Acesso em: 27 de maio de 2009.

Universidade Federal do ABC - UFABC. Ementa do curso. Disponível em: <http://www.ufabc.edu.br/index.php?option=com_content&view=article&id=1568> Acesso em: 27 de maio de 2009.

Universidade Federal de Goiás - UFG. Ementa do curso. Disponível em: <http://engenhariadesoftware.inf.br/publico/introducao-es-2009-1-sem.pdf> Acesso em: 27 de maio de 2009.

Universidade Federal de São Carlos - UFSCAR. Ementa do curso. Disponível em: <http://www2.dc.ufscar.br/~bcc/gradecurricular.php> Acesso em: 27 de maio de 2009.

Universidade Federal de Viçosa - UFV. Ementa do curso. Disponível em: <http://www.dpi.ufv.br/disciplinas/inf323/> Acesso em: 27 de maio de 2009.

Universidade Estadual de Maringá - UEM. Ementa do curso. Disponível em: <http://www.pen.uem.br/html/pen/graduacao/cursos/cco.pdf> Acesso em: 27 de maio de 2009.

Universidade Federal do Pará - UFP. Ementa do curso. Disponível em: <http://www.cultura.ufpa.br/informatica/interna.php?page=estrutura> Acesso em: 27 de maio de 2009.

Universidade Federal do Rio Grande do Norte - UFRN. Ementa do curso. Disponível em: <http://www.dimap.ufrn.br/~jair/ES/> Acesso em: 27 de maio de 2009.

Writing Services

Essay Writing
Service

Find out how the very best essay writing service can help you accomplish more and achieve higher marks today.

Assignment Writing Service

From complicated assignments to tricky tasks, our experts can tackle virtually any question thrown at them.

Dissertation Writing Service

A dissertation (also known as a thesis or research project) is probably the most important piece of work for any student! From full dissertations to individual chapters, we’re on hand to support you.

Coursework Writing Service

Our expert qualified writers can help you get your coursework right first time, every time.

Dissertation Proposal Service

The first step to completing a dissertation is to create a proposal that talks about what you wish to do. Our experts can design suitable methodologies - perfect to help you get started with a dissertation.

Report Writing
Service

Reports for any audience. Perfectly structured, professionally written, and tailored to suit your exact requirements.

Essay Skeleton Answer Service

If you’re just looking for some help to get started on an essay, our outline service provides you with a perfect essay plan.

Marking & Proofreading Service

Not sure if your work is hitting the mark? Struggling to get feedback from your lecturer? Our premium marking service was created just for you - get the feedback you deserve now.

Exam Revision
Service

Exams can be one of the most stressful experiences you’ll ever have! Revision is key, and we’re here to help. With custom created revision notes and exam answers, you’ll never feel underprepared again.