ANÁLISE DE MODELOS DE DOCUMENTOS DE GAME DESIGN E PROPOSTA DE PADRÃO UNIFICADO

Tamanho: px
Começar a partir da página:

Download "ANÁLISE DE MODELOS DE DOCUMENTOS DE GAME DESIGN E PROPOSTA DE PADRÃO UNIFICADO"

Transcrição

1 ANÁLISE DE MODELOS DE DOCUMENTOS DE GAME DESIGN E PROPOSTA DE PADRÃO UNIFICADO Steven David Feuerstein Mariasch (IC) e Luciano Silva (Orientador) Apoio: PIVIC Mackenzie Resumo A documentação de Game Design é fruto da descentralização de tarefas do processo de desenvolvimento e publicação de jogos digitais, como também do número elevado de pessoas em algumas equipes de desenvolvimento. Alguns autores apontam que não há um padrão industrial para o formato da documentação, diferentemente do que acontece em outras indústrias, como a de cinema. Com o objetivo de apresentar uma proposta de padrão de Documento de Game Design, este artigo pretende ajudar iniciantes na área e a indústria de jogos digitais. Para identificar interesses comuns nos documentos, alguns formatos existentes foram analisados. Em seguida, um novo formato foi criado, fazendo uso da linguagem de programação literada CWEB para se obter um novo documento. Finalmente, é proposto que o modelo seja apresentado em eventos das áreas abordadas para que seja dado início às discussões sobre seu uso como padrão. Palavras-chave: Padrões de Documentação de Jogos, Game Design Document, Game Design, Engenharia de Software Abstract Game Design documentation exists due to the decentralization of the game development process and game publishing tasks, and also due to the high number of members in some development teams. Some authors indicate that there are no standard formats for documenting designs, differently from what happens in other industries, like the film industry. Aiming to propose a standard format for Game Design Documents, this article intends to help people that are starting to learn about Game Design and its industry as well. In order to identify common interests between different documents of this type, some of the existing formats were analyzed. After that, a new format was created, making use of the CWEB literate programming language in order to obtain a new document. Finally, it is proposed that this new model be presented in some events of the related areas so the conversations for using it as a standard could be started. Keywords: Game Documentation Patterns, Game Design Document, Game Design, Software Engineering 1

2 VII Jornada de Iniciação Científica Introdução Para pessoas que desejam se tornar game designers ou mesmo pessoas que desejam desenvolver um jogo, é normal que se questionem como se estrutura um documento de game design, o que ele deve conter e o porquê disso, assim poderão num estágio mais avançado de desenvolvimento, por exemplo, satisfazer às exigências de uma publicadora que tenha estabelecido a necessidade de se apresentar uma documentação (ROUSE, 2005, p. 307). O mais correto seria ir em busca do padrão da indústria. Fullerton, Swain e Hoffman (2008, p. 395, tradução nossa) são bem diretos sobre este suposto padrão: A indústria de jogos digitais não tem um formato padrão para documentação de designs. Seria legal se existisse uma fórmula definida ou estilo para se seguir, [...] mas isso simplesmente não existe 1. Um exemplo de pessoa que foi em busca de um formato padrão quando era aspirante à game designer, é Rouse (2005, p. 356). Ele sabia que os roteiros de Hollywood tinham um formato preciso, e acreditava que deveria ter algo semelhante para documentos de design. Entretanto, descobriu que não havia um formato e que cada um que escreve um documento de design cria o próprio formato. A engenharia de jogos digitais é uma herança ainda não padronizada, na área de documentação, da Engenharia de Software. É interessante mencionar que o escopo deste projeto não foca padrões em Game Design, já descritos na obra de Björk e Holopainen (2005). A obra demonstra uma série de possibilidades de design em diversos tipos de jogos digitais. O grupo conhecido como Gang of Four (GAMMA; et al., 2000), ou apenas GoF, descreveu uma série de padrões de projeto orientados a objeto. Eles também descreveram quais são os elementos essenciais de um padrão (Ibid., 2000, p. 19): o nome do padrão, o problema (em que situação aplicar o padrão), a solução e as consequências. Muito embora o GoF estivesse descrevendo padrões de projeto, sua descrição de padrão é completamente aplicável à padrões de documentação. Este artigo apresenta uma proposta de padrão de documentação para Game Design, caracterizando os elementos essenciais que um Documento de Game Design deve possuir, utilizando a linguagem literada CWEB para aumentar as funcionalidades deste tipo de documento com a adição de trechos de código ao mesmo. Este artigo está organizado da seguinte forma: a Seção 2 apresenta o referencial teórico; a Seção 3 apresenta o método; 1 Texto original: The game industry has no standard format for documenting designs. It would be nice if there were a set formula or style to follow, [ ], but this simply does not exist. (FULLERTON; SWAIN; HOFFMAN, 2008, p. 395) 2

3 a Seção 4 apresenta os resultados e discussão; finalmente, a Seção 5 apresenta as conclusões. 2. Referencial Teórico 2.1 Processos de Projeto de Jogos Introdução A indústria de jogos digitais contemporânea apresenta um modelo de divisão de tarefas por especialização. Há dois tipos principais de tarefas nessa indústria: desenvolver e publicar os jogos. O desenvolvimento dos jogos é responsabilidade das empresas chamadas desenvolvedoras, e a publicação é responsabilidade das empresas chamadas publicadoras ou, em inglês, publishers. Algumas empresas publicam seus próprios jogos, e são chamadas por muitos de desenvolvedoras independentes. Quando uma desenvolvedora necessita recursos financeiros para desenvolver, ou quando deseja que uma publicadora veicule um de seus jogos, ela deve primeiro apresentar para uma publicadora um documento chamado e descrito por Pedersen (2009, p. 73, tradução nossa) como One Pager, que explica e vende o conceito de seu game para publicadoras e desenvolvedoras e coloca suas ideias e visão em um documento conciso. Um One Pager pode ter uma ou duas páginas [ ] 2. A partir do momento em que a publicadora aprova o projeto, ou mesmo quando ela fornece um projeto próprio para uma dada desenvolvedora, ela financia todos os custos do projeto. Dado o grau de complexidade dos grandes projetos de jogos atualmente, são necessárias diversas pessoas trabalhando nestes projetos para cumprir os prazos estabelecidos. Por exemplo, segundo uma reportagem de Reynolds (2009), a equipe que estava desenvolvendo o jogo Assassin s Creed II (Ubisoft Montreal, 2009) contava com aproximadamente 450 pessoas. Estas pessoas são especializadas em diversos segmentos necessários para se desenvolver jogos, como arte (desde desenhos conceituais até modelagem e texturização dos personagens e cenários), programação (como da Inteligência Artificial e da Física) e design (Game Design, Character Design e Level Design). Antigamente, os jogos digitais não eram apenas desenvolvidos na forma de software, eram também desenvolvidos na forma de hardware, como relata Wozniak ( ; SMITH, 2007, 2 Texto original: The one pager explains and sells your game s concept to publishers and developers and puts your ideas and vision into a concise document. A one pager can be one or two pages [ ] (PEDERSEN, 2009, p. 79). 3

4 VII Jornada de Iniciação Científica p , tradução nossa) sobre sua experiência ao desenvolver o jogo Breakout (Atari, 1978): Eu comecei na verdade desenhando os esquemas de uma forma que uma TV mostraria luz na tela linha por linha. Eu não dormi por quatro dias e noites durante este projeto. Durante o dia, eu desenhei o design em papel, desenhando-o claramente o suficiente para que um técnico pudesse pegar o design e ligar os chips. 3 Wozniak foi um dos pioneiros na área de design de jogos, apesar de que atualmente esta área possui mais responsabilidades e dificilmente acarrete no desenho de hardware. Segundo Andrade (2008, p. 36), Os designers são os profissionais que pensam como o jogo deve ser. [...] Os designers têm que pensar, descrever e documentar cada detalhe do jogo. O game designer deve pensar no funcionamento geral do jogo, nas regras, nos desafios e, principalmente, em como deve manter o jogador interessado. Apesar de Wozniak também ter usado, sem muito valor, uma técnica de documentação de design, atualmente ela é muito comum e importante nas empresas de desenvolvimento de jogos. Alguns documentos são usados, sendo o mais importante o de Game Design que [...] é o coração e a alma de todos os documentos que giram em torno de um game em desenvolvimento. É o verdadeiro documento de planta baixa, e seu objetivo é ilustrar como se deve jogá-lo e apresentar uma descrição abrangente de todos os aspectos, para que a equipe de desenvolvimento possa, de fato, criar o game (SCHUYTEMA, 2008, p. 100). Por meio deste documento, do game designer - responsável pelo documento -, e de reuniões constantes que as equipes se guiam e resolvem dúvidas durante o projeto. As próximas seções descrevem algumas das etapas do processo de desenvolvimento de jogos Game Design Em sua essência, o desenvolvimento de jogos depende do Game Design. Não há o que desenvolver se não há uma ideia pré-elaborada. As atividades de Game Design se situam na criação de um contexto que dá rumo à todas as outras atividades relacionadas ao 3 Texto original: I began by actually drawing the schematics so a TV would display light on the screen line by line. I didn t sleep for four days and nights during this project. During the day, I drew the design on paper, drawing it out clearly enough so that a technician could take the design and wire chips together (WOZNIAK; SMITH, 2007, p ) 4

5 desenvolvimento de jogos, como também garantem que a equipe de desenvolvimento compreendeu este contexto e a execução do trabalho corresponde ao esperado. O cargo do principal responsável da equipe por elaborar o design corresponde ao Game Designer. Este profissional pode ter como formação acadêmica diversas origens, devido à dimensão extensa de possibilidades de design, entre outros. Uma das etapas que nem sempre está presente em um jogo, devido ao estilo a que este pertence, é a de Level Design. Esta etapa é descrita na seção a seguir Level Design Chamado por alguns autores como Design do ambiente (SCHUYTEMA, 2008, p. 277), geralmente, apenas jogos que são organizados em fases ou em um mundo específico possuem atividades relacionadas com Level Design. Tanto Schuytema (Ibid., p. 278) quanto Fullerton, Swain e Hoffman (2008, p ) concordam que se uma equipe e/ou projeto forem pequenos, cabe ao game designer a execução desta tarefa, e caso a equipe e/ou o projeto forem grandes, esta tarefa pode ser atribuída à um profissional do tipo level designer. Cabe ao responsável desta tarefa responsabilidades como as seguintes: implementar os designs das fases, elaborar conceitos para fases, testar as fases e trabalhar junto ao designer para melhorar o gameplay em geral (Ibid., p. 362). Estas responsabilidades estão diretamente ligadas à documentação, seja consultando-a ou adicionando rascunhos dos mapas das fases ao documento. A tarefa de implementação é descrita na próxima seção Implementação A implementação corresponde a tornar a visão do jogo digital uma realidade em termos de produto digital. Em equipes numerosas, os profissionais envolvidos são: programadores, artistas visuais, engenheiros de garantia de qualidade (QA engineers), profissionais de mídia especializada, e os próprios level designers (FULLERTON; SWAIN; HOFFMAN, 2008, p , tradução nossa). A próxima seção descreve como são realizados os testes de um jogo, que é diferente dos testes realizados na programação. 5

6 VII Jornada de Iniciação Científica Testes A atividade de testes de um jogo, conhecida em inglês como atividade de playtesting, acontece durante todo o processo de design e fornece uma introspecção sobre o jogo alcançar ou não as metas de experiência estabelecidas para o jogador. Basicamente, esta atividade corresponde ao designer observar à distância uma ou várias pessoas (playtesters) jogando, sem interferir ou ajudar nesta experiência. Idealmente, os playtesters não devem conhecer o conteúdo do GDD, sendo que apenas a análise de seu ato de jogar deve indicar ao designer aspectos a serem alterados ou mantidos no design (Ibid., p. 248). Na próxima seção, há uma avaliação de diferentes propostas de modelos de Documentos de Game Design, como também a análise de um metamodelo. 2.2 Documentos de Jogos O Modelo de Rouse Rouse (2005) propõe uma documentação de Game Design dividida nas seguintes seções: sumário, introdução/visão geral, mecânica do jogo, Inteligência Artificial (IA), elementos do jogo, visão geral da história, progressão do jogo e menus do sistema. É importante ressaltar que nem todos os jogos necessitarão de todas estas seções e, portanto, não há como definir uma ordem específica para o modelo O Modelo de Schuytema Schuytema (2008, p. 100) afirma que a complexidade do sumário do Documento de Game Design necessária para cada game designer depende da escala e do escopo do projeto em desenvolvimento e que não há modelo que sirva para todas as opções. O modelo do autor é composto pelo seguinte sumário (Ibid. p. 101): I. Visão geral essencial 6

7 a. Resumo b. Aspectos fundamentais c. Golden nuggets II. Contexto do jogo a. História do jogo b. Eventos anteriores c. Principais jogadores III. Objetos essenciais do jogo a. Personagens b. Armas c. Estruturas d. Objetos IV. Conflitos e soluções V. Inteligência Artificial VI. Fluxo do jogo VII. Controles VIII. Variações de jogo IX. Definições X. Referências O Modelo de Fullerton, Swain e Hoffman Em nenhum momento os autores mencionam o uso de um sumário em seu modelo. Ao invés disso, mencionam que documentos eficientes comunicam a informação principal de 50 a 100 páginas. A visão de Rouse (2005), já mencionada anteriormente e que incluí um sumário em seu modelo, parece ser mais eficiente, já que leva o interessado em alguma parte específica do documento direto ao seu ponto de interesse. Em geral, os conteúdos de um GDD podem ser divididos nas seguintes áreas: Visão Geral e Vision Statement; Público, Plataforma e Marketing; 7

8 VII Jornada de Iniciação Científica Gameplay; Personagens (se tiver); História (se tiver); Mundo (se tiver); Lista de Mídias O GDD também pode incluir detalhes técnicos, caso não for adotado o uso do Documento de Especificação Técnica. Os autores ainda quiseram deixar claro que o modelo deles não é um padrão que funcionaria para qualquer jogo, mas fornece ideias sobre os tipos de seções a incluir O Metamodelo de Björk e Holopainen Björk e Holopainen (2005, cap. 2) definem um framework para descrição de jogos baseado em atividades que o jogador realiza nos jogos. Este framework não tem como intenção descrever um GDD, mas um jogo. Por esse motivo e por não se basear em seções que o Game Designer tem que documentar, este framework, ou metamodelo de GDD, é bem diferente dos modelos de GDD apresentados pelos outros autores. O metamodelo fornece conceitos para se discutir que os autores chamam de Primeira Ordem do Game Design, os componentes de um jogo que fazem do gameplay ser possível. Esses componentes básicos de jogos podem então ser usados para descrever o que os autores chamam de Conceitos de Segunda Ordem do Game Design, que seriam os padrões de Game Design. É importante ressaltar que o metamodelo não tem como intenção definir o que é um jogo digital ou o ato de jogar, pelo contrário, ele é indiferente à definição do que é ou deveria ser um jogo digital. Os componentes do jogo são divididos em quatro categorias no framework: Holística, Fronteira, Temporal e Estrutural. Essas categorias seriam uma reflexão de quatro possíveis maneiras de se ver a atividade de jogar um jogo. Os componentes holísticos descrevem como essa atividade é separada de outras atividades; os componentes fronteiriços limitam as possíveis ações do jogador no/durante o jogo; os componentes temporais descrevem o fluxo do jogo; e os componentes estruturais definem os elementos físicos e lógicos necessários para conter e manipular o estado do jogo. 8

9 3. Método 3.1 Proposta de Documentação Unificada para Game Design, Implementação e Testes Introdução Apesar dos três modelos analisados e do metamodelo serem diferentes entre si, é possível identificar pontos em comum, apenas dispostos de maneira diferente. Também foi identificado que nenhum dos modelos visa uma aproximação do processo de desenvolvimento de código para o jogo, algo que distancia o software de sua documentação, o que pode prejudicar o interesse de programadores na leitura de documentos - justamente algo que é contrário a ideia de comunicar a visão geral do jogo para a equipe já mencionado anteriormente (FULLERTON; SWAIN; HOFFMAN, 2009, p. 394). A proposta de padrão a ser apresentada nesta seção leva em consideração as ideias dos autores, os pontos em comum dos modelos analisados e o objetivo de criar um modelo independente de gênero. Considerando essencial a transmissão para a equipe da ideia geral do jogo através do GDD, é interessante adicionar ao padrão de GDD um processo de transmissão contínua desta ideia, adicionando elementos de código diretamente no texto através de programação literada em CWEB com a intenção de aumentar as funções do próprio documento e as consultas ao mesmo realizadas pela equipe Modelo de Desenvolvimento em Espiral Considerando que o GDD está sempre em crescimento (por muitas vezes chamado de documento vivo) durante o desenvolvimento do jogo, dado que o desenvolvimento de jogos digitais é um meio inerentemente colaborativo em que a visão geral do jogo deve ser transmitida com clareza a toda equipe de desenvolvimento (FULLERTON; SWAIN; HOFFMAN, 2008, p. 394), é sensato o uso de um processo de desenvolvimento em espiral, que representa um processo sempre em crescimento. Entretanto, é importante ressaltar que a criação de um GDD pertence, principalmente, à etapa de pré-produção de um jogo digital, e que a segunda etapa, a de produção, depende da aprovação da primeira (VAN SLYKE, 2009). Sendo assim, grande parte do conteúdo criado no processo a ser descrito na Seção 3.3, corresponde a um protótipo de jogo digital, e não ao próprio jogo, e será determinante na aprovação de um projeto. Porventura, durante a etapa de produção, pode ocorrer alguma mudança no escopo do projeto que faça com que haja uma atualização no GDD, dando continuidade ao conceito de documento vivo e à espiral. 9

10 VII Jornada de Iniciação Científica O modelo tradicional do processo de desenvolvimento de software em espiral, conforme a Figura 1, é dividido em quatro setores (SOMMERVILLE, 2003, p ). No primeiro, definição de objetivos, são definidos os objetivos específicos para essa fase do projeto, representada por um loop na espiral. No segundo, avaliação e redução de riscos, para cada um dos riscos de projeto identificados, é realizada uma análise detalhada e são tomadas providências para reduzir esses riscos. Em seguida, em desenvolvimento e validação, um modelo de desenvolvimento (como prototipação evolucionária ou modelo em cascata) é escolhido para o sistema. Finalmente, em planejamento, o projeto é revisto e toma-se uma decisão sobre a necessidade de continuar a espiral. Figura 1 - Modelo do Processo de Desenvolvimento de Software em Espiral (SOMMERVILLE, 2003). Entretanto, para o GDD, foram definidas três fases gerais para este processo, conforme a Figura 2: Design, Implementação e Testes. 10

11 Figura 2 - O Modelo de Desenvolvimento do GDD em uma Espiral de Três Fases. Além da descrição do processo relacionado com a espiral na Seção 4.2, a Seção 4.3 apresenta seções elementares de qualquer GDD, seguida do fluxo que o documento deve seguir, com um exemplo no final da Seção Processo A primeira fase, Design, é uma atividade independente da programação do jogo, produzindo mídia a partir de um documento inicial de design. Já a segunda fase, Implementação, vem da equipe de programação que associa a primeira fase, ou seja, toda a mídia produzida ao código. Finalmente, uma equipe de testes do documento analisa, na fase Testes, os documentos obtidos após a compilação em CWEB nesta iteração da espiral. A Figura 3 representa o diagrama de atividades em UML referente a este processo. 11

12 VII Jornada de Iniciação Científica Figura 3: Diagrama de Atividades UML do Processo de Desenvolvimento Relacionado ao Padrão A próxima seção, Documento de Game Design Unificado e Independente de Gênero, indica quais são as seções elementares que um GDD independente de gênero deve possuir, além de seções e subseções complementares que podem fornecer mais informações para os interessados em sua leitura. 4 Resultados e Discussão 4.1 Documento de Game Design Unificado e Independente de Gênero Após o estudo comparativo realizado anteriormente entre os modelos de GDD que usam o formato de seções, foram definidas seções elementares presentes em qualquer GDD moderno para fazer parte do padrão, dispostas a seguir: 1 Histórico do Design 2 Sumário 3 Gameplay 3.1 Visão Geral 3.2 Elementos do Jogo 3.3 Controles 12

13 4 Mecânica 5 Menus do Sistema Estas seções são descritas nos modelos apresentados anteriormente, e podem ter variação de nome e localização, dependendo do autor. Pode-se dizer que elas são elementares de qualquer GDD por estarem presentes nos modelos analisados, como também não são dependentes de gênero e por isso foram escolhidas para compor um modelo unificado. Outras seções analisadas não são essencialmente independentes de gêneros e dificultam a criação de um modelo unificado independente de gênero. As duas primeiras seções representam elementos pré-textuais, e são escritas e atualizadas ao fim de cada nova iteração da espiral, não havendo uma necessidade de serem implementadas no jogo em si. Conforme o gênero e estilo do jogo a ser documentado, outras seções ou subseções podem ser acrescentadas, como: Inteligência Artificial, Progressão do Jogo/Level Design, Contexto do Jogo, Conflitos e Soluções, Variações de Jogo, História, Mundo, e Personagens. 4.2 Fluxo do Documento Partindo da fase de Design, após todo o processo criativo inicial, deve-se documentar em um arquivo com a extensão.w o que foi obtido. O Histórico do Design deve registrar a versão inicial, incrementando o número da versão na medida em que ocorrem novas iterações da espiral e indicando as mudanças ocorridas. Com esta primeira documentação, no formato de texto - definindo seções como a Visão Geral e a Mecânica do Jogo, por exemplo -, o documento segue para a fase de Implementação, no qual é desenvolvido o código correspondente em CWEB e disposto logo em seguida ao respectivo trecho implementado. Feito isso, os programas CTANGLE e CWEAVE (KNUTH; LEVY, 2002) são executados, tendo como entrada o arquivo com a extensão.w. O primeiro programa gera como produto um código fonte em C baseado no código em CWEB, e o segundo programa gera como produto um arquivo de texto do tipo.tex, conforme a Figura 4. Figura 4: Adaptação de figura do site literateprogramming.com, de um exemplo de entrada e de saídas dos programas CTANGLE e CWEAVE 4 4 Fonte: <http://www.literateprogramming.com/cweave.jpg>. Acesso em: 12 Maio

14 VII Jornada de Iniciação Científica A espiral segue para a fase de testes, na qual o arquivo executável obtido da compilação do código fonte em C e a documentação obtida do arquivo de extensão.tex são validados. Ao término desta fase, avalia-se a necessidade de continuar a espiral, retomando todo o processo ou finalizando o procedimento. Na seção a seguir, há um exemplo do uso de CWEB integrado à Documentação de Game Design. 4.3 Exemplo de Construção de Documento Knuth (2010) adaptou como exemplo para CWEB o jogo de texto Adventure (CROWTHER; WOODS, 1975), originalmente escrito em FORTRAN. Na época em que o jogo original foi desenvolvido, não existia o conceito de GDD, como também não foi desenvolvido por uma equipe numerosa. A adaptação feita por Knuth consiste basicamente na tradução direta do código em FORTRAN para CWEB, usando, inclusive, os comentários originais como documentação do código (WOODS; KNUTH, 2002). É de se esperar, portanto, que esta versão em CWEB não apresente o formato de um GDD, mas sim de um programa documentado. Esta versão apresenta a seguinte divisão de seções, na respectiva ordem (Ibid., tradução nossa): Introdução, Vocabulário, Dados da Caverna, Conexões da Caverna, Estruturas de Dados para Objetos, Dados de Objetos, Entrada em Baixo Nível, Loop de Controle Principal, Verbos Simples, Ativos Líquidos, Outras Ações, Movimentos, Números Aleatórios, Elementos de Duendes, Fechando a Caverna, Morte e Ressurreição, Pontuação, Executando o Programa, Índice Remissivo e um Sumário automático. Para fins de demonstração do processo em espiral, foi criada uma simulação na qual o programa documentado de Knuth, adventure.w (KNUTH, 2010), representa o protótipo de um jogo mais elaborado no setor de arte e jogabilidade, e foi concebido nas primeiras duas fases deste processo. A fase de Testes valida o arquivo executável obtido após a execução do CTANGLE, entretanto, identifica que o documento gerado após a execução do CWEAVE não possuí as seções elementares de um GDD, ou não está organizado com a nomenclatura correta das seções, e informa a equipe de Design que a avaliação da validade das seções depende disto. Começa uma nova fase de Design, na qual a equipe reorganiza as seções antigas em seções do GDD unificado apresentado neste artigo. As seguintes alterações foram feitas: foi adicionada no início a seção de Histórico do Design, já descrevendo as alterações; o Sumário foi reposicionado logo após o Histórico do Design; a seção de Introdução se torna uma subseção de Visão Geral, antecedendo uma nova descrição da ideia geral do jogo; Gameplay abriga tanto a subseção Elementos do Jogo, que passa a representar as antigas Estruturas de Dados para Objetos, Dados de Objetos, e Ativos Líquidos, quanto abriga a subseção Controles, que representa as 14

15 antigas Vocabulário, Entrada em Baixo Nível, Verbos Simples, Outras Ações, e Movimentos, como também abriga Pontuação ; a nova seção Mecânica recebe as subseções Loop de Controle Principal, Números Aleatórios, Morte e Ressurreição, e Executando o Programa ; a seção Level Design é adicionada e apresenta o conteúdo de Dados da Caverna, Conexões da Caverna, e Fechando a Caverna ; Personagens passa a ser a nova seção de Elementos de Duendes ; e parte da seção Vocabulário representa comandos que desencadeiam a abertura de algum tipo de Menu, como o de ajuda, e estes comandos devem ser indicados na nova seção Menus do Sistema; finalmente, o Índice Remissivo permanece no mesmo lugar. A nova ordem corresponde ao seguinte: 1 Histórico do Design 1.1 Versão Versão Sumário 3 Gameplay 3.1 Visão Geral Introdução Conceito do Jogo 3.2 Elementos do Jogo Estruturas de Dados para Objetos Dados de Objetos Ativos Líquidos 3.3 Controles Vocabulário Entrada em Baixo Nível Verbos Simples Outras Ações Movimentos 3.4 Pontuação 15

16 VII Jornada de Iniciação Científica Mecânica 4.1 Loop de Controle Principal 4.2 Números Aleatórios 4.3 Morte e Ressurreição 4.4 Executando o Programa 5 Level Design 5.1 Dados da Caverna 5.2 Conexões da Caverna 5.3 Fechando a Caverna 6 Personagens 6.1 Elementos de Duendes 7 Menus do Sistema 7.1 Vocabulário 8 Índice Remissivo Em CWEB, diferentemente de subseções, que são definidas pelo prefixo composto pelo e um espaço em branco, uma seção principal tem seu título definido pelo um texto e um ponto (.). Todo o conteúdo escrito até o próximo título deste estilo corresponde a uma seção. O programa CWEAVE foi programado de uma maneira para identificar estes símbolos de seção ao ser executado e determinar sua posição e número correspondente, para então criar o Sumário automaticamente (KNUTH; LEVY, 2002). Em termos de alterações no arquivo adventure.w, isto corresponde, usando como exemplo o momento em que algumas alterações já foram feitas e a nova seção Mecânica vai ser criada, ao seguinte: Loop de Controle Principal, Números Aleatórios, Morte e Ressurreição, e Executando o Programa, que são definidas como seções principais (começam com o seguido de texto e um ponto), são recortados individualmente e colocados um em seguida do outro, a partir do fim da seção anterior - Gameplay. Os prefixos de seção principal são substituídos por prefixos de subseção. Finalmente, no princípio da seção (antes da primeira subseção), o prefixo de seção principal é adicionado, seguido pelo texto Mecânica sem aspas e um ponto. Estas alterações não afetam o funcionamento do 16

17 programa gerado pelo CTANGLE, tendo como explicação a própria origem do nome deste programa (Ibid., tradução nossa): O programa CTANGLE tem este nome porque ele recebe uma certa teia e remaneja as seções de sua estrutura em forma de teia em uma ordem exigida pela linguagem C; a vantagem de se programar em CWEB é de que os algoritmos podem ser expressos em uma forma desemaranhada, com cada seção explicada separadamente. 5 Já na fase de Implementação, eventuais atualizações são feitas no código para refletir as mudanças feitas na fase anterior. Novamente, a fase de Testes valida o arquivo executável e verifica por alguma falha no documento de texto. Este processo todo é continuado caso tenha sido identificado a necessidade de alguma mudança ou atualização. 5. Conclusão É certo que para o GDD e o processo de desenvolvimento associado criados neste trabalho passarem a ser de conhecimento da indústria e serem usados, é necessário que eles sejam aprimorados e apresentados de alguma maneira, como em um evento da área, por exemplo. Futuramente, o padrão pode ser testado com uma equipe desenvolvendo um jogo, enquanto outra equipe desenvolve o mesmo jogo sem o uso do padrão, para que haja uma avaliação do desempenho do padrão. Outra sugestão é adaptar o metamodelo para que ele possa descrever um jogo de uma maneira independente de seu gênero, a fim de fornecer uma alternativa aos modelos baseados em gênero. Também é importante consultar membros estabelecidos da indústria internacional de jogos em relação ao formato criado, tanto para analisar novas propostas quanto divulgar o formato. Mesmo que o padrão criado neste trabalho não seja aplicado na indústria, seja com um documento dependente ou não de gênero, é interessante divulgar que um padrão de documentação para Game Design é possível. Além dessas possibilidades, outras questões surgiram durante o decorrer da pesquisa que podem ser temas para novas pesquisas. Ao analisar os processos de desenvolvimento de jogos digitais, foi constatado que certos pontos são muito semelhantes à Engenharia de Software, ou mesmo idênticos. Aparentemente, devido à descentralização de tarefas - onde profissionais de outras áreas que não são da Tecnologia da Informação (TI) - como artistas - se juntaram ao desenvolvimento de jogos, houve a criação de processos de 5 Texto original: The CTANGLE program is so named because it takes a given web and moves the sections from their web structure into the order required by C; the advantage of programming in CWEB is that the algorithms can be expressed in untangled form, with each section explained separately (KNUTH; LEVY, 2002) 17

18 VII Jornada de Iniciação Científica desenvolvimento em paralelo à Engenharia de Software, onde havia mais profissionais específicos de TI. Um trabalho futuro pode, por exemplo, determinar se a suposição anterior é válida, como também determinar se um GDD corresponde ao documento de especificação de software (SRS, do inglês Software Requirements Specification) e se o cargo de Game Designer equivale ao cargo de Arquiteto de Software, e outras comparações entre Game Design e Engenharia de Software. Referências ANDRADE, P. M. F. D. As Carreiras no Mercado de Games. In: BOBANY, A. Videogame Arte. Teresópolis: Novas Idéias, p. 36. BJÖRK, S.; HOLOPAINEN, J. An Activity-Based Framework for Describing Games. In:. Patterns in Game Design. Boston: Charles River Media, Cap. 2. FULLERTON, T.; SWAIN, C.; HOFFMAN, S. Playtesting In:. Game Design Workshop. 2nd. ed. Burlington: Elsevier Inc, Cap. 9.. Team Structures. In:. Game Design Workshop. 2nd. ed. Burlington: Elsevier Inc, Cap The Design Document. In:. Game Design Workshop. 2nd. ed. Burlington: Elsevier Inc, Cap. 14. GAMMA, E. et al. Introdução. In:. Padrões de Projeto: soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, Cap. 1. KNUTH, D. E. ADVENT, Disponível em: <http://www-csstaff.stanford.edu/~uno/programs/advent.w.gz>. Acesso em: 05 Maio ; LEVY, S. The CWEB System of Structured Documentation, Disponível em: <http://www.literateprogramming.com/cweb.pdf>. Acesso em: 05 Maio PEDERSEN, R. E. The Game Design Process. In:. Game Design Foundations. 2nd. ed. Plano: Wordware Publishing, Cap 5. REYNOLDS, C. Assassin's Creed II dev team triples in size. NowGamer, Disponível em: <http://www.nowgamer.com/news/513/assassins-creed-ii-triples-size-of-dev-team>. Acesso em: 03 Maio ROUSE, R. The Design Document. In:. Game design: theory & practice. 2nd. ed. Plano: Wordware Publishing, Inc, Cap

19 SCHUYTEMA, P. O documento de design. In:. Design de Games: Uma Abordagem Prática. São Paulo: Cengage Learning, Cap. 5.. Design do ambiente In:. Design de Games: Uma Abordagem Prática. São Paulo: Cengage Learning, Cap. 12. SOMMERVILLE, I. Processos de software. In:. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Weasley, Cap. 3. VAN SLYKE, B. How a Game Gets Made: A Game's Journey from Concept to Store Shelves. GameCareerGuide.com, Disponível em: <http://www.gamecareerguide.com/features/745/how_a_game_gets_made_a_games_.php>. Acesso em: 16 Abr WOODS, D.; KNUTH, D. E. ADVENTURE, Disponível em: <http://www.literateprogramming.com/adventure.pdf>. Acesso em: 05 Maio WOZNIAK, S.; SMITH, G. iwoz. New York: W. W. Norton & Company, Jogos Digitais Citados Adventure. Will Crowther; Don Woods, Assassin s Creed II. Ubisoft. Ubisoft Montreal, Breakout. Atari, Contato: e 19

AULA 2. Aspectos Técnicos. Luciano Roberto Rocha. www.lrocha.com. MBA em Marketing Digital SOCIAL GAMES

AULA 2. Aspectos Técnicos. Luciano Roberto Rocha. www.lrocha.com. MBA em Marketing Digital SOCIAL GAMES MBA em Marketing Digital SOCIAL GAMES AULA 2 Luciano Roberto Rocha Aspectos Técnicos Ponta Grossa, 31 de agosto de 2013 ROTEIRO Papéis Processos Plataformas Ferramentas 2 PAPÉIS O desenvolvimento de um

Leia mais

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2 Modelo de domínio Introdução! 1 Modelos de Domínio! 1 Identificação de classes conceituais! 2 Estratégia para identificar classes conceituais! 2 Passos para a elaboração do modelo de domínio! 2 Passo 1

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro

Metodologia para Planejamento, Execução e Controle de Teste de Software. Roteiro Metodologia para Planejamento, Execução e Controle de Teste de Software Arilo Claudio Dias Neto - acdn@cos.ufrj.br Gladys Machado P. S. Lima - gladysmp@cos.ufrj.br Guilherme Horta Travassos - ght@cos.ufrj.br

Leia mais

4 Cursos de nível superior no Brasil para formação de Designers de Games

4 Cursos de nível superior no Brasil para formação de Designers de Games 4 Cursos de nível superior no Brasil para formação de Designers de Games Este Capítulo apresenta o levantamento realizado dos cursos de nível superior no Brasil voltados para a formação de Designers de

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

Engenharia de Software Unidade I Visão Geral

Engenharia de Software Unidade I Visão Geral Conteúdo programático Engenharia de Software Unidade I Visão Geral Prof. Francisco Gerson A. de Meneses O que é Produtos de Software Distribuição de Software Um sistema de Software O software em um cenário

Leia mais

A construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da

A construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da 6 Conclusões No âmbito do framework teórico da Engenharia Semiótica, este trabalho faz parte de um esforço conjunto para desenvolver ferramentas epistêmicas que apóiem a reflexão do designer durante o

Leia mais

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO MP1 DATA 05/03/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

EVIL ANGEL CHIBI - SCAPE OF DEATH

EVIL ANGEL CHIBI - SCAPE OF DEATH EVIL ANGEL CHIBI - SCAPE OF DEATH RAMARI, L.; FERNANDES, F.N. RESUMO O artigo apresenta o funcionamento de jogos na plataforma 2D, descrevendo os principais tipos de jogos e mostrando os passos básicos

Leia mais

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ. Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Campus Ponta Grossa ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Ponta Grossa 2012 ANDRÉ LUIS CORDEIRO DE FARIA RELATÓRIO DE ESTÁGIO Trabalho elaborado pelo

Leia mais

INTELIGÊNCIA ARTIFICIAL E SUA APLICABILIDADE NOS JOGOS

INTELIGÊNCIA ARTIFICIAL E SUA APLICABILIDADE NOS JOGOS INTELIGÊNCIA ARTIFICIAL E SUA APLICABILIDADE NOS JOGOS Aline Ferraz da Silva 1 Carine Bueira Loureiro 2 Resumo: Este artigo trata do projeto de Trabalho

Leia mais

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes

Engenharia de Software: Introdução. Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Engenharia de Software: Introdução Mestrado em Ciência da Computação 2008 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. UML 3. O Processo Unificado 1. Captura de requisitos 2.

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Alinhamento Estratégico. A importância do alinhamento entre a TI e o Negócio e o método proposto pelo framework do CobiT 4.1

Alinhamento Estratégico. A importância do alinhamento entre a TI e o Negócio e o método proposto pelo framework do CobiT 4.1 Conhecimento em Tecnologia da Informação Alinhamento Estratégico A importância do alinhamento entre a TI e o Negócio e o método proposto pelo framework do CobiT 4.1 2010 Bridge Consulting Apresentação

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

EMENTAS DAS DISCIPLINAS

EMENTAS DAS DISCIPLINAS EMENTAS DAS DISCIPLINAS CURSO EDUCAÇÃO A DISTÂNCIA (EAD) SISTEMAS PARA INTERNET INTRODUÇÃO À COMPUTAÇÃO 68 A disciplina estuda a área da informática como um todo e os conceitos fundamentais, abrangendo

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

DESENVOVIMENTO DE GAMES APRESENTAÇÃO. MARCELO HENRIQUE DOS SANTOS http://www.marcelohsantos.com marcelosantos@outlook.com

DESENVOVIMENTO DE GAMES APRESENTAÇÃO. MARCELO HENRIQUE DOS SANTOS http://www.marcelohsantos.com marcelosantos@outlook.com JOGOS DIGITAIS DESENVOVIMENTO DE GAMES APRESENTAÇÃO MARCELO HENRIQUE DOS SANTOS http://www.marcelohsantos.com marcelosantos@outlook.com Bacharel em Sistema de Informação Pós Graduado em Games : Produção

Leia mais

- Aula 03_2012 - Profa. Ms. Karen Reis

- Aula 03_2012 - Profa. Ms. Karen Reis Protótipos de Jogos Digitais - Aula 03_2012-1 Design de Games Só temos GAMES quando há: contexto interessante, direcionados a um objetivo e limitado por regras. Os games da era pós-digital se apoiam em

Leia mais

Unidade II MODELAGEM DE PROCESSOS

Unidade II MODELAGEM DE PROCESSOS Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que

Leia mais

CONFECÇÃO DE SITE, PARA ABRIGO DE PORTIFÓLIO PESSOAL, INTEIRAMENTE EM FLASH Tales Garcia Fernandes Universidade Estadual de Campinas

CONFECÇÃO DE SITE, PARA ABRIGO DE PORTIFÓLIO PESSOAL, INTEIRAMENTE EM FLASH Tales Garcia Fernandes Universidade Estadual de Campinas CONFECÇÃO DE SITE, PARA ABRIGO DE PORTIFÓLIO PESSOAL, INTEIRAMENTE EM FLASH Tales Garcia Fernandes Universidade Estadual de Campinas Introdução A proposta inicial desse projeto era a de confeccionar um

Leia mais

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental Ajuda ao SciEn-Produção 1 Este texto de ajuda contém três partes: a parte 1 indica em linhas gerais o que deve ser esclarecido em cada uma das seções da estrutura de um artigo cientifico relatando uma

Leia mais

O USO E DESENVOLVIMENTO DE SOFTWARES EM MICRO E PEQUENAS EMPRESAS* THE USE AND DEVELOPMENT OF SOFTWARE IN MICRO AND SMALL ENTERPRISES

O USO E DESENVOLVIMENTO DE SOFTWARES EM MICRO E PEQUENAS EMPRESAS* THE USE AND DEVELOPMENT OF SOFTWARE IN MICRO AND SMALL ENTERPRISES O USO E DESENVOLVIMENTO DE SOFTWARES EM MICRO E PEQUENAS EMPRESAS* THE USE AND DEVELOPMENT OF SOFTWARE IN MICRO AND SMALL ENTERPRISES Rodolfo Miranda Pereira 1 Tania Fatima Calvi Tait 2 Donizete Carlos

Leia mais

O PROJETO DE PESQUISA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

O PROJETO DE PESQUISA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza O PROJETO DE PESQUISA Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza ROTEIRO Escolher um tema de pesquisa Por onde começar? Ler para aprender Estrutura do Projeto de Pesquisa A Definição

Leia mais

Programação de Computadores

Programação de Computadores Programação de Computadores INTRODUÇÃO AOS ALGORITMOS E À PROGRAMAÇÃO DE COMPUTADORES PARTE 1 Renato Dourado Maia Instituto de Ciências Agrárias Universidade Federal de Minas Gerais Programas e Programação

Leia mais

EMENTAS DAS DISCIPLINAS

EMENTAS DAS DISCIPLINAS EMENTAS DAS DISCIPLINAS CURSO SUPERIOR DE TECNOLOGIA EM SISTEMAS PARA INTERNET Introdução à Computação A disciplina apresenta a área da Computação como um todo, desde a história e a evolução dos computadores

Leia mais

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador> FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido

Leia mais

COMO ELABORAR UM ARTIGO CIENTÍFICO

COMO ELABORAR UM ARTIGO CIENTÍFICO 1 Modelo de Artigo de periódico baseado na NBR 6022, 2003. Título do artigo, centralizado. COMO ELABORAR UM ARTIGO CIENTÍFICO Andersown Becher Paes de Barros * Ideraldo Bonafé ** RESUMO Este trabalho apresenta

Leia mais

Orientações para o Planejamento e Realização do Projeto Final

Orientações para o Planejamento e Realização do Projeto Final Orientações para o Planejamento e Realização do Projeto Final Simone Diniz Junqueira Barbosa Versão: 1.0.4 Orientações para o Planejamento e Realização do Projeto Final Sumário 1 Introdução... 3 2 Projeto

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

O que é um processo de software?

O que é um processo de software? O que é um processo de software? Um conjunto de atividades realizadas por pessoas cujo objetivo é desenvolvimento ou evolução de software e sua documentação. Atividades genéricas em todos os processos:

Leia mais

APLICAÇÃO DE MAPAS MENTAIS DURANTE O BRAINSTORM DE UM JOGO DIGITAL

APLICAÇÃO DE MAPAS MENTAIS DURANTE O BRAINSTORM DE UM JOGO DIGITAL APLICAÇÃO DE MAPAS MENTAIS DURANTE O BRAINSTORM DE UM JOGO DIGITAL Davi Shinji Mota Kawasaki (PIBIC/Fundação Araucária), José Augusto Fabri (Orientador), e-mail: davishinjik@gmail.com; fabri@utfpr.edu.br.

Leia mais

COMO ELABORAR UM ARTIGO CIENTÍFICO RESUMO. Palavras-chave: Artigo Científico. Normalização. NBR 6022/03.

COMO ELABORAR UM ARTIGO CIENTÍFICO RESUMO. Palavras-chave: Artigo Científico. Normalização. NBR 6022/03. ARTIGO CIENTÍFICO Texto com autoria declarada que apresenta e discute ideias, métodos, técnicas, processos e resultados de diversas áreas do conhecimento (ABNT/NBR 6022:2003). 2.1.1 Modelo de artigo COMO

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Apresentação da Disciplina Edirlei Soares de Lima Objetivos da Disciplina Apresentar e discutir técnicas avançadas de Análise e Projeto de

Leia mais

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10)

Questionário. A ferramenta auxilia na alocação de Não (0) x x x. Satisfatório (5) complexidade de um caso de uso? de uso (72) Sim (10) Questionário Nível Avaliado Gerador de plano de teste Gerador de dados Função/característica do produto Gestão dos dados do plano de teste (51) Perguntas Pontuação Selenium BadBoy Canoo A ferramenta auilia

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT Disciplina: Modelagem a Programação Orientada a Objetos

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

AUTOR(ES): VINICIUS RUIZ PONTES SILVA, JAQUELINE CRISTINA DA SILVA, JOÃO PAULO DE OLIVEIRA HONESTO

AUTOR(ES): VINICIUS RUIZ PONTES SILVA, JAQUELINE CRISTINA DA SILVA, JOÃO PAULO DE OLIVEIRA HONESTO Anais do Conic-Semesp. Volume 1, 2013 - Faculdade Anhanguera de Campinas - Unidade 3. ISSN 2357-8904 TÍTULO: IMPLEMENTAÇÃO DE UM SISTEMA PARA INTERCÂMBIOS ESTUDANTIS CATEGORIA: CONCLUÍDO ÁREA: ENGENHARIAS

Leia mais

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

ESTUDO DA MELHOR METODOLOGIA PARA A DIFUSÃO DE VÍDEOS EXPLICATIVOS DE FENÔMENOS METEOROLÓGICOS

ESTUDO DA MELHOR METODOLOGIA PARA A DIFUSÃO DE VÍDEOS EXPLICATIVOS DE FENÔMENOS METEOROLÓGICOS Ana Beatriz Mesquita (CPTEC/INPE) ESTUDO DA MELHOR METODOLOGIA PARA A DIFUSÃO DE VÍDEOS EXPLICATIVOS DE FENÔMENOS METEOROLÓGICOS Metodologia do trabalho realizado referente a gravação e expansão dos vídeos

Leia mais

Curso de Licenciatura em Informática

Curso de Licenciatura em Informática Curso de Licenciatura em Informática Disciplina: Análise e Projeto de Sistemas Professor: Rafael Vargas Mesquita EXERCÍCIOS SOBRE MODELAGEM DE CASOS DE USO Exercício 1: construa um Diagrama de Casos de

Leia mais

Engenharia de Requisitos- como Previnir e Reduzir Riscos

Engenharia de Requisitos- como Previnir e Reduzir Riscos Engenharia de Requisitos- como Previnir e Reduzir Riscos Natasha de Souza Arruda natasha.arruda@ig.com.br FGS Resumo:Engenharia de Requisitos é um dos processos fundamentais para o desenvolvimento de software.

Leia mais

Metodologias de desenvolvimento de jogos

Metodologias de desenvolvimento de jogos Metodologias de desenvolvimento de jogos Truesoft? A Truesoft é um grupo independente de desenvolvedores de jogos digitais. Nossos objetivos: Criar experiências divertidas e criativas em jogos digitais.

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

Leia mais

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador Sistemas de Informação Prof. Anderson D. Moura Um programa de computador é composto por uma seqüência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um

Leia mais

Interface gráfica para compiladores gratuitos baseados em linha de comando disponíveis na internet

Interface gráfica para compiladores gratuitos baseados em linha de comando disponíveis na internet 1. Autores Interface gráfica para compiladores gratuitos baseados em linha de comando disponíveis na internet Luciano Eugênio de Castro Barbosa Flavio Barbieri Gonzaga 2. Resumo O custo de licenciamento

Leia mais

Utilização da modelagem UML em um sistema de gerenciamento de uma franquia do setor de alimentação

Utilização da modelagem UML em um sistema de gerenciamento de uma franquia do setor de alimentação Utilização da modelagem UML em um sistema de gerenciamento de uma franquia do setor de alimentação Use of UML modeling in a management system for a food franchising Richard B. N. Vital, Tatiane M. Vital.

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO Departamento: Disciplina: Pré-Requisitos: I D E N T I F I C A Ç Ã O Sistemas de Informação Engenharia de Software Aplicada (ESA) Engenharia de Software (ES) CH: 7 Curso: Bacharelado em Sistemas de Informação

Leia mais

Padrões de projeto 1

Padrões de projeto 1 Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois

Leia mais

Guerra Civil. Variante da Guerra Civil. Resumo do Jogo. George R.R. Martin, O Festim dos Corvos

Guerra Civil. Variante da Guerra Civil. Resumo do Jogo. George R.R. Martin, O Festim dos Corvos Variante da Guerra Civil Guerra Civil E por que não? Favorece-o, sempre foi assim. Ele se parece com você, pensa como você, que pretende lhe dar Dorne, não se incomode em negá-lo. Eu li sua carta. As palavras

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4.

Guia de Atualização PROJURIS WEB 4.5. Manual do Técnico Atualização - ProJuris Web 4.5. Manual do Técnico Atualização - ProJuris Web 4. Guia de Atualização PROJURIS WEB 4.5 Por: Fabio Pozzebon Soares Página 1 de 11 Sistema ProJuris é um conjunto de componentes 100% Web, nativamente integrados, e que possuem interface com vários idiomas,

Leia mais

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

REVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

ANÁLISE E PROJETO DE SISTEMAS PARA WEB II Processos

ANÁLISE E PROJETO DE SISTEMAS PARA WEB II Processos ANÁLISE E PROJETO DE SISTEMAS PARA WEB II Processos PROCESSO DE SOFTWARE Ao falar de processo, no contexto da Engenharia de Software, estamos nos referindo ao processo de desenvolvimento de software. O

Leia mais

Tópicos de Ambiente Web. Modulo 2 Processo de desenvolvimento de um site Professora: Sheila Cáceres

Tópicos de Ambiente Web. Modulo 2 Processo de desenvolvimento de um site Professora: Sheila Cáceres Tópicos de Ambiente Web Modulo 2 Processo de desenvolvimento de um site Professora: Sheila Cáceres Roteiro Motivação Desenvolvimento de um site Etapas no desenvolvimento de software (software:site) Analise

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

Medindo a Produtividade do Desenvolvimento de Aplicativos

Medindo a Produtividade do Desenvolvimento de Aplicativos Medindo a Produtividade do Desenvolvimento de Aplicativos Por Allan J. Albrecht Proc. Joint SHARE/GUIDE/IBM Application Development Symposium (October, 1979), 83-92 IBM Corporation, White Plains, New York

Leia mais

GUIA DE REDAÇÃO PARA TRABALHO DE EM974

GUIA DE REDAÇÃO PARA TRABALHO DE EM974 GUIA DE REDAÇÃO PARA TRABALHO DE EM974 CONSIDERAÇÕES GERAIS O objetivo deste documento é informar a estrutura e a informação esperadas num texto de Trabalho de Graduação. O conteúdo do texto deverá ser

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 06 PROFª BRUNO CALEGARO Santa Maria, 27 de Setembro de 2013. Revisão aula anterior Desenvolvimento Ágil de Software Desenvolvimento e entrega

Leia mais

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº 45671 Guilherme

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Bibliografia UML Guia de consulta rápida Douglas Marcos da Silva Editora: Novatec UML Guia do usuário Grady Booch James Rumbaugh Ivair Jacobson Editora: Campus

Leia mais

Uma nova perspectiva sobre a experiência digital do cliente

Uma nova perspectiva sobre a experiência digital do cliente Uma nova perspectiva sobre a experiência digital do cliente Redesenhando a forma como empresas operam e envolvem seus clientes e colaboradores no mundo digital. Comece > Você pode construir de fato uma

Leia mais

1 Inicie um novo. Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007. projeto

1 Inicie um novo. Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007. projeto Guia de Referência Rápida de Gerenciamento de Projeto para o Project 2007 1 Inicie um novo Antes de começar um novo, uma organização deve determinar se ele se enquadra em suas metas estratégicas. Os executivos

Leia mais

DESENVOLVIMENTO DE JOGOS DIGITAIS. Desmistificando o desenvolvimento de games e mercado de trabalho

DESENVOLVIMENTO DE JOGOS DIGITAIS. Desmistificando o desenvolvimento de games e mercado de trabalho DESENVOLVIMENTO DE JOGOS DIGITAIS Desmistificando o desenvolvimento de games e mercado de trabalho 2 Caravieri Modesto Professor de Programação e Banco de Dados I IFSP (SALTO Analise e Desenvolvimento

Leia mais

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 4º PERÍODO - 7º MÓDULO AVALIAÇÃO A4 DATA 22/10/2009 ENGENHARIA DE USABILIDADE

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 4º PERÍODO - 7º MÓDULO AVALIAÇÃO A4 DATA 22/10/2009 ENGENHARIA DE USABILIDADE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 4º PERÍODO - 7º MÓDULO AVALIAÇÃO A4 DATA 22/10/2009 ENGENHARIA DE USABILIDADE 2009/2 GABARITO COMENTADO QUESTÃO 1: Quando nos referimos à qualidade da interação

Leia mais

3. Fase de Planejamento dos Ciclos de Construção do Software

3. Fase de Planejamento dos Ciclos de Construção do Software 3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de

Leia mais

TÉCNICAS DE ESTRUTURAÇÃO PARA DESIGN RESPONSIVO: AMPLIANDO A USABILIDADE NO AMBIENTE WEB

TÉCNICAS DE ESTRUTURAÇÃO PARA DESIGN RESPONSIVO: AMPLIANDO A USABILIDADE NO AMBIENTE WEB TÉCNICAS DE ESTRUTURAÇÃO PARA DESIGN RESPONSIVO: AMPLIANDO A USABILIDADE NO AMBIENTE WEB Tiago Volpato 1, Claudete Werner 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil tiagovolpatobr@gmail.com,

Leia mais

Os anexos não serão contabilizados. O limite de 3 (três) folhas é para o texto da estratégia de mídia, sem os anexos.

Os anexos não serão contabilizados. O limite de 3 (três) folhas é para o texto da estratégia de mídia, sem os anexos. Florianópolis, 20 de janeiro de 2016. Para que todos tenham o mesmo entendimento, abaixo os questionamentos formulados por interessado na licitação Concorrência nº 23/2015, bem como os devidos esclarecimentos

Leia mais

Prototype, um Design Patterns de Criação

Prototype, um Design Patterns de Criação Prototype, um Design Patterns de Criação José Anízio Pantoja Maia Este artigo tem como finalidade compreender o funcionamento do padrão de projeto prototype, serão abordados os participantes que compõe

Leia mais

Tutorial de Matlab Francesco Franco

Tutorial de Matlab Francesco Franco Tutorial de Matlab Francesco Franco Matlab é um pacote de software que facilita a inserção de matrizes e vetores, além de facilitar a manipulação deles. A interface segue uma linguagem que é projetada

Leia mais

SOFTWARE PARA GERENCIAMENTO DE REBANHOS BOVINOS: DESENVOLVIMENTO E AVALIAÇÃO PELA SOFTHOUSE

SOFTWARE PARA GERENCIAMENTO DE REBANHOS BOVINOS: DESENVOLVIMENTO E AVALIAÇÃO PELA SOFTHOUSE SOFTWARE PARA GERENCIAMENTO DE REBANHOS BOVINOS: DESENVOLVIMENTO E AVALIAÇÃO PELA SOFTHOUSE Marcelo Pereira Barbosa Email: mpbbarbosa@bol.com.br Vínculo: Professor da Escola Técnica Estadual "Lauro Gomes"

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

ATIVIDADES PRÁTICAS SUPERVISIONADAS

ATIVIDADES PRÁTICAS SUPERVISIONADAS ATIVIDADES PRÁTICAS SUPERVISIONADAS 10ª Série Automação Industrial Engenharia Elétrica A atividade prática supervisionada (ATPS) é um procedimento metodológico de ensino-aprendizagem desenvolvido por meio

Leia mais

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

X Encontro Nacional de Educação Matemática Educação Matemática, Cultura e Diversidade Salvador BA, 7 a 9 de Julho de 2010

X Encontro Nacional de Educação Matemática Educação Matemática, Cultura e Diversidade Salvador BA, 7 a 9 de Julho de 2010 INVESTIGAÇÃO MATEMÁTICA: UMA EXPERIÊNCIA DE ENSINO Bruno Rodrigo Teixeira 1 Universidade Estadual de Londrina - UEL bruno_matuel@yahoo.com.br Camila Rosolen 2 Universidade Estadual de Londrina - UEL camilarosolen@yahoo.com.br

Leia mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

DESENVOLVIMENTO DE ALGORITMO PARA FUNÇÃO MULTILÍNGUE DO SOFTWARE TROPLUX

DESENVOLVIMENTO DE ALGORITMO PARA FUNÇÃO MULTILÍNGUE DO SOFTWARE TROPLUX DESENVOLVIMENTO DE ALGORITMO PARA FUNÇÃO MULTILÍNGUE DO SOFTWARE TROPLUX Pedro Vítor Sousa Ribeiro Universidade Federal de Alagoas pedrovsribeiro@gmail.com Ricardo Carvalho Cabús Universidade federal de

Leia mais

Introdução a INGENIAS:

Introdução a INGENIAS: Universidade do Estado do Rio Grande do Norte UERN Universidade Federal Rural do Semi-Árido UFERSA Mestrado em Ciência da Computação MCC Disciplina: Engenharia de Software Orientada a Agentes Professores:

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

A IMPORTÂNCIA DAS FERRAMENTAS DO MARKETING NAS PEQUENAS EMPRESAS. PAES, Paulo César 1 SARAIVA, Antonio Wanderlan Pereira 2 RESUMO

A IMPORTÂNCIA DAS FERRAMENTAS DO MARKETING NAS PEQUENAS EMPRESAS. PAES, Paulo César 1 SARAIVA, Antonio Wanderlan Pereira 2 RESUMO A IMPORTÂNCIA DAS FERRAMENTAS DO MARKETING NAS PEQUENAS EMPRESAS PAES, Paulo César 1 SARAIVA, Antonio Wanderlan Pereira 2 RESUMO A Ferramenta do Marketing nas Pequenas Empresas atualmente vem sendo utilizada

Leia mais

Desenvolvendo um Ambiente de Aprendizagem a Distância Utilizando Software Livre

Desenvolvendo um Ambiente de Aprendizagem a Distância Utilizando Software Livre Desenvolvendo um Ambiente de Aprendizagem a Distância Utilizando Software Livre Fabrício Viero de Araújo, Gilse A. Morgental Falkembach Programa de Pós-graduação em Engenharia de Produção - PPGEP Universidade

Leia mais

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA)

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Apresentação O programa de Pós-graduação Lato Sensu em Engenharia de Software Orientada a Serviços

Leia mais

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.

Leia mais

Transformação de um Modelo de Empresa em Requisitos de Software

Transformação de um Modelo de Empresa em Requisitos de Software Transformação de um Modelo de Empresa em Requisitos de Software Fábio Levy Siqueira 1 and Paulo Sérgio Muniz Silva 2 1 Programa de Educação Continuada da Poli-USP, São Paulo, Brazil 2 Escola Politécnica

Leia mais

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Francisco Xavier Freire Neto 1 ; Aristides Novelli Filho 2 Centro Estadual de Educação Tecnológica

Leia mais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais Notas da Aula 17 - Fundamentos de Sistemas Operacionais 1. Gerenciamento de Memória: Introdução O gerenciamento de memória é provavelmente a tarefa mais complexa de um sistema operacional multiprogramado.

Leia mais

Ginga-NCL com objetos de mídia SSML embutidos Relatório Técnico: Requisitos

Ginga-NCL com objetos de mídia SSML embutidos Relatório Técnico: Requisitos PUC-Rio - Departamento de Informática Ginga-NCL com objetos de mídia SSML embutidos Relatório Técnico: Requisitos Rafael Diniz Matrícula: 1312398 5 de agosto de 2014 Sumário 1 Introdução 2 1.1 Propósito...........................................

Leia mais

Design de Games: A importância da estética. utilizada na interface de um game.

Design de Games: A importância da estética. utilizada na interface de um game. Design de Games: A importância da estética utilizada na interface de um game. Edival Oliveira Lago Filho* Resumo: O artigo tem como objetivo, refletir sobre a importância da estética aplicada sobre o design

Leia mais