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

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

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

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS

MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS 127 MODELAGEM VISUAL DE UM SOFTWARE PARA O GERENCIAMENTO DAS COMUNICAÇÕES EM GESTÃO DE PROJETOS VISUAL MODELING OF SOFTWARE FOR COMMUNICATION MANAGEMENT IN PROJECT MANAGEMENT Ricardo Rall 1 Arilson José

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

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

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

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

- 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

Guião A. Descrição das actividades

Guião A. Descrição das actividades Proposta de Guião para uma Prova Grupo: Ponto de Encontro Disciplina: Inglês, Nível de Continuação, 11.º ano Domínio de Referência: Um Mundo de Muitas Culturas Duração da prova: 15 a 20 minutos 1.º MOMENTO

Leia mais

Desenvolvimento de um Framework de Jogos 3D para Celulares

Desenvolvimento de um Framework de Jogos 3D para Celulares Desenvolvimento de um Framework de Jogos 3D para Celulares Fabrício Brasiliense Departamento de Informática e Estatística(INE) Universidade Federal de Santa Catarina (UFSC) Campus Universitário Trindade-

Leia mais

MÉTODO ÁGIL XP (EXTREME PROGRAMMING)

MÉTODO ÁGIL XP (EXTREME PROGRAMMING) MÉTODO ÁGIL XP (EXTREME PROGRAMMING) Luciano Malaquias de Souza* * RESUMO: Como o emprego dos métodos para desenvolvimento de software tem se tornado mais popular, existe uma grande demanda, pela industria,

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

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.

desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org. desenvolvimento de software em indústria, comunidades acadêmicas e científicas uma fábrica de software?... joa@ufrpe.br silvio@cesar.org.br laboratórios de desenvolvimento... Produção de Software: histórico

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE THE REQUIREMENTS ELICITATION ACCORDING TO THE VOLERE METHOD

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE THE REQUIREMENTS ELICITATION ACCORDING TO THE VOLERE METHOD LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE THE REQUIREMENTS ELICITATION ACCORDING TO THE VOLERE METHOD RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem

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

Casos de Teste de Uso: uma alternativa de especificação para o desenvolvimento dirigido por testes

Casos de Teste de Uso: uma alternativa de especificação para o desenvolvimento dirigido por testes Casos de Teste de Uso: uma alternativa de especificação para o desenvolvimento dirigido por testes Simone Tejo Salgado Beato Instituto de Pesquisas Tecnológicas de São Paulo SP Brasil sisalgado@uol.com.br

Leia mais

Searching for Employees Precisa-se de Empregados

Searching for Employees Precisa-se de Empregados ALIENS BAR 1 Searching for Employees Precisa-se de Empregados We need someone who can prepare drinks and cocktails for Aliens travelling from all the places in our Gallaxy. Necessitamos de alguém que possa

Leia mais

GUIÃO A. Ano: 9º Domínio de Referência: O Mundo do Trabalho. 1º Momento. Intervenientes e Tempos. Descrição das actividades

GUIÃO A. Ano: 9º Domínio de Referência: O Mundo do Trabalho. 1º Momento. Intervenientes e Tempos. Descrição das actividades Ano: 9º Domínio de Referência: O Mundo do Trabalho GUIÃO A 1º Momento Intervenientes e Tempos Descrição das actividades Good morning / afternoon / evening, A and B. For about three minutes, I would like

Leia mais

Proposta de Modelos de Documentação de Design para Jogos 2D

Proposta de Modelos de Documentação de Design para Jogos 2D Proposta de Modelos de Documentação de Design para Jogos 2D Frederico Boussada Alves 1, Márlon Oliveira da Silva 2 Faculdade de Ciências Exatas e Comunicação (FACEC) Universidade Presidente Antônio Carlos

Leia mais

O Ciclo de Vida do Desenvolvimento de Sistemas i

O Ciclo de Vida do Desenvolvimento de Sistemas i O Ciclo de Vida do de Sistemas i O Ciclo de Vida do de Sistemas ( SDLC Systems Development Life Cycle), conhecido também com o ciclo de vida do software refere-se aos estágios de concepção, projeto, criação

Leia mais

A Aplicação da Linguagem de Modelagem Unificada (U.M.L.): Novas Perspectivas para o Desenvolvimento de Games Educacionais

A Aplicação da Linguagem de Modelagem Unificada (U.M.L.): Novas Perspectivas para o Desenvolvimento de Games Educacionais A Aplicação da Linguagem de Modelagem Unificada (U.M.L.): Novas Perspectivas para o Desenvolvimento de Games Educacionais William Santos Programa de Pós-Graduação em Modelagem Computacional Faculdade de

Leia mais

Modelagem de informações de. construçãocapítulo1: Capítulo. Objetivo do capítulo

Modelagem de informações de. construçãocapítulo1: Capítulo. Objetivo do capítulo construçãocapítulo1: Capítulo 1 Modelagem de informações de A modelagem de informações de construção (BIM) é um fluxo de trabalho integrado baseado em informações coordenadas e confiáveis sobre um empreendimento,

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

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

Jogos Eletrônicos. Apresentação da Disciplina. Edirlei Soares de Lima

Jogos Eletrônicos. Apresentação da Disciplina. Edirlei Soares de Lima <edirlei.lima@uniriotec.br> Jogos Eletrônicos Apresentação da Disciplina Edirlei Soares de Lima Objetivos da Disciplina Apresentar os fundamentos de jogos eletrônicos, game design e as técnicas para o

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

Welcome to Lesson A of Story Time for Portuguese

Welcome to Lesson A of Story Time for Portuguese Portuguese Lesson A Welcome to Lesson A of Story Time for Portuguese Story Time is a program designed for students who have already taken high school or college courses or students who have completed other

Leia mais

Geração automática de suíte de teste para GUI a partir de Rede de Petri

Geração automática de suíte de teste para GUI a partir de Rede de Petri Raquel Jauffret Guilhon Geração automática de suíte de teste para GUI a partir de Rede de Petri Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

ENG1000 Introdução à Engenharia

ENG1000 Introdução à Engenharia ENG1000 Introdução à Engenharia Aula 03 Game Design Document Edirlei Soares de Lima Game Design Document Um Game Design Document (GDD) é um documento que descreve todos aspectos

Leia mais

Atuação do designer na indústria de games eletrônicos

Atuação do designer na indústria de games eletrônicos Atuação do designer na indústria de games eletrônicos Bruno Fujikuro Carlos José Felipe Favila Introdução à Informática 2011 Em tese, o papel do designer de games é projetar jogos para PC, consoles, celulares,

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

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering.

Parte I Requirement Engineering. Gestão de Projectos Informáticos. Gestão do Âmbito (Scope Management) Requirement Engineering. Parte I Requirement Engineering Gestão de Projectos Informáticos Gestão do Âmbito (Scope Management) Requirement Engineering Introduzir as noções requisitos de sistema e processo de engª de requisitos

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

IBM Rational Requirements Composer

IBM Rational Requirements Composer IBM Requirements Composer Aprimore os resultados do projeto por meio da melhor definição e gerenciamento de requisitos Destaques Obter maior agilidade, foco no cliente, qualidade e menor tempo de lançamento

Leia mais

Fabiano Naspolini de Oliveira fabiano@fabricadejogos.net www.fabricadejogos.net

Fabiano Naspolini de Oliveira fabiano@fabricadejogos.net www.fabricadejogos.net Fabiano Naspolini de Oliveira fabiano@fabricadejogos.net www.fabricadejogos.net Conceito de Game Design Game Designer e Perfil Diversão e Teoria do Fluxo (Flow) Processo de Produção e o Game Design Técnicas

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

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

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com

Análise e Projeto de Sistemas de Informação. Andrêza Leite andreza.lba@gmail.com Análise e Projeto de Sistemas de Informação Andrêza Leite andreza.lba@gmail.com Roteiro Sistemas de Informação Ciclo de Desenvolvimento de SI Projeto Análise Estruturada Análise Orientada a Objetos Como

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

Desenvolvimento com grandes equipes: desafios e soluções. Charles Marcel de Barros (Lead Game Programmer)

Desenvolvimento com grandes equipes: desafios e soluções. Charles Marcel de Barros (Lead Game Programmer) Desenvolvimento com grandes equipes: desafios e soluções Charles Marcel de Barros (Lead Game Programmer) O desafio Desenvolver jogos em equipe: Prazo Qualidade para o jogador Qualidade de sistema Por que

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

CONSTRUÇÃO DE SOFTWARE

CONSTRUÇÃO DE SOFTWARE CONSTRUÇÃO DE SOFTWARE Náthilla Tavares Fagundes, Pablo Galvão, Wytor Venancio Rodrigues Faculdade de Tecnologia SENAC Goiânia/GO (SENAC/GO) Av. Independência número 1002 - CEP 74645-010 Setor Leste Vila

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

Visual Library: Uma Biblioteca para Criação de Ferramentas de Modelagem Gráfica

Visual Library: Uma Biblioteca para Criação de Ferramentas de Modelagem Gráfica Visual Library: Uma Biblioteca para Criação de Ferramentas de Modelagem Gráfica Tiago A. Gameleira 1, Raimundo Santos Moura 2, Luiz Affonso Guedes 1 1 Universidade Federal do Rio Grande do Norte (UFRN)

Leia mais

Introdução Engenharia de Software

Introdução Engenharia de Software Introdução Engenharia de Software Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 EMENTA Parte 1 Conceitos de Engenharia de Software. Processo de desenvolvimento

Leia mais

A história de UML e seus diagramas

A história de UML e seus diagramas A história de UML e seus diagramas Thânia Clair de Souza Vargas Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) Florianópolis, SC Brazil thania@inf.ufsc.br Abstract.

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

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

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF

Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF Msc. Daniele Carvalho Oliveira Doutoranda em Ciência da Computação UFU Mestre em Ciência da Computação UFU Bacharel em Ciência da Computação UFJF 1. Identificação de um problema a ser implementado 2. Análise

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE E SEU USO NO EXÉRCITO BRASILEIRO

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE E SEU USO NO EXÉRCITO BRASILEIRO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE E SEU USO NO EXÉRCITO BRASILEIRO LAURO DE SOUZA SILVA * Resumo: O presente trabalho versa sobre a importância de um processo de desenvolvimento padronizado na instituição

Leia mais

PX: Um Processo de Desenvolvimento de Software Adaptado para Projetos de Pequeno Porte

PX: Um Processo de Desenvolvimento de Software Adaptado para Projetos de Pequeno Porte PX: Um Processo de Desenvolvimento de Software Adaptado para Projetos de Pequeno Porte Renata Burmeister Bäuerle Faculdade de Informática Centro Universitário Ritter dos Reis (UniRitter) 98.840-440 Porto

Leia mais

A abordagem da Engenharia Semiótica para o desenvolvimento de software centrado no usuário

A abordagem da Engenharia Semiótica para o desenvolvimento de software centrado no usuário A abordagem da Engenharia Semiótica para o desenvolvimento de software centrado no usuário Jair Cavalcanti Leite Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do

Leia mais

Uma Introdução a Engenharia de Software e Sistemas

Uma Introdução a Engenharia de Software e Sistemas Uma Introdução a Engenharia de Software e Sistemas Centro de Informática - Universidade Federal de Pernambuco Engenharia da Computação Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville

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

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Metodologia de Desenvolvimento de Sistemas: Análise Essencial, Estruturada e Orientada a Objetos

Metodologia de Desenvolvimento de Sistemas: Análise Essencial, Estruturada e Orientada a Objetos Metodologia de Desenvolvimento de Sistemas: Análise Essencial, Estruturada e Orientada a Objetos Luan Santos da Silva e Silva luan_silva@hotmail.com Discente do 8º Período do curso de Sistemas de Informação

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

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum

Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Test-Module: uma ferramenta para gerenciamento de testes de software integrada ao FireScrum Audrey B. Vasconcelos, Iuri Santos Souza, Ivonei F. da Silva, Keldjan Alves Centro de Informática Universidade

Leia mais

Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados

Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados Maria das Dores Rosa Alves¹, Marcia Izabel Fugisawa Souza¹ ¹Embrapa Informática Agropecuária Caixa postal 6014 Campinas, SP

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

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

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

Análise de Performance de Frameworks de Desenvolvimento Mobile Multiplataforma

Análise de Performance de Frameworks de Desenvolvimento Mobile Multiplataforma 347 Análise de Performance de Frameworks de Desenvolvimento Mobile Multiplataforma Kamile A. Wahlbrinck, Bruno B. Boniati Universidade Federal de Santa Maria (UFSM) Caixa Postal 54 98.400-000 Frederico

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso Casos de Uso O que é Casos de Uso Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início

Leia mais

Análise e Implementação de um Sistema para o Gerenciamento de Estágios Curriculares na Faculdade Piauiense FAP/Parnaíba *

Análise e Implementação de um Sistema para o Gerenciamento de Estágios Curriculares na Faculdade Piauiense FAP/Parnaíba * Análise e Implementação de um Sistema para o Gerenciamento de Estágios Curriculares na Faculdade Piauiense FAP/Parnaíba * Ely N. Barros 1, Mayllon V. da Silva 1, Rodrigo Augusto Rocha Souza Baluz 1 1 Bacharelado

Leia mais

- Aula 1 - ARQUITETURA DE COMPUTADORES

- Aula 1 - ARQUITETURA DE COMPUTADORES - Aula 1 - ARQUITETURA DE COMPUTADORES Em arquitetura de computadores serão estudados aspectos da estrutura e do funcionamento dos computadores. O objetivo é apresentar de forma clara e abrangente a natureza

Leia mais

Introdução ao Design

Introdução ao Design Introdução ao Design João Arthur e Guilherme Germoglio Coordenação de Pós-graduação em Informática - COPIN 16/10/2008 João Arthur e Guilherme Germoglio 1/ 33 Roteiro 1 Introdução Objetivos 2 Definições

Leia mais

Guião M. Descrição das actividades

Guião M. Descrição das actividades Proposta de Guião para uma Prova Grupo: Inovação Disciplina: Inglês, Nível de Continuação, 11.º ano Domínio de Referência: O Mundo do trabalho Duração da prova: 15 a 20 minutos 1.º MOMENTO Guião M Intervenientes

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

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

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

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

Acadêmica: Giselle Mafra Schlosser Orientador: Everaldo Artur Grahl

Acadêmica: Giselle Mafra Schlosser Orientador: Everaldo Artur Grahl AVALIAÇÃO DA QUALIDADE DO CÓDIGO FONTE ESCRITO EM PL/SQL Acadêmica: Giselle Mafra Schlosser Orientador: Everaldo Artur Grahl Roteiro Introdução Objetivos do trabalho Fundamentação teórica Desenvolvimento

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0

Plano de Projeto G Stock. G Stock. Plano de Projeto. Versão 1.0 Plano de Projeto G Stock Plano de Projeto G Stock Versão 1.0 Histórico das Revisões Data Versão Descrição Autores 10/09/2010 1.0 Descrição inicial do plano de projeto Denyson José Ellís Carvalho Isadora

Leia mais

GUIÃO A. What about school? What s it like to be there/here? Have you got any foreign friends? How did you get to know them?

GUIÃO A. What about school? What s it like to be there/here? Have you got any foreign friends? How did you get to know them? GUIÃO A Prova construída pelos formandos e validada pelo GAVE, 1/7 Grupo: Chocolate Disciplina: Inglês, Nível de Continuação 11.º ano Domínio de Referência: Um Mundo de Muitas Culturas 1º Momento Intervenientes

Leia mais

Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL

Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL Engenharia Reversa para Recuperação de Modelos de Sistemas Desenvolvidos em PL/SQL Rodnei Couto 1, Luana Lachtermacher 1, Soeli Fiorini 1, Akeo Tanabe 1, Gustavo Carvalho 1, Arndt von Staa 1, Ricardo Choren

Leia mais

Racing the Beam: uma história das Materialidades do videogame Atari

Racing the Beam: uma história das Materialidades do videogame Atari Racing the Beam: uma história das Materialidades do videogame Atari Letícia Perani Mestre em Comunicação pela Universidade do Estado do Rio de Janeiro (Uerj). E-mail: leticiaperani@yahoo.com.br Resenha

Leia mais

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV Adaptado a partir de Gerald Kotonya and Ian Sommerville 1 Objectivos Introduzir as noções requisitos de sistema e processo

Leia mais

ATENAS: Um Sistema Gerenciador de Regras de Negócio

ATENAS: Um Sistema Gerenciador de Regras de Negócio 1. Introdução ATENAS: Um Sistema Gerenciador de Regras de Negócio Geraldo Zimbrão da Silva (IM/UFRJ) Victor Teixeira de Almeida (COPPE/UFRJ) Jano Moreira de Souza (COPPE/UFRJ) Francisco Gonçalves Pereira

Leia mais

Design Patterns STRATEGY EMERSON BARROS DE MENESES

Design Patterns STRATEGY EMERSON BARROS DE MENESES Design Patterns STRATEGY EMERSON BARROS DE MENESES 1 Breve Histórico Sobre Design Patterns A origem dos Design Patterns (Padrões de Desenho ou ainda Padrões de Projeto) vem do trabalho de um arquiteto

Leia mais

Guia de Introdução ao Windows SharePoint Services

Guia de Introdução ao Windows SharePoint Services Guia de Introdução ao Windows SharePoint Services - Windows SharePoint Services... Page 1 of 11 Windows SharePoint Services Guia de Introdução ao Windows SharePoint Services Ocultar tudo O Microsoft Windows

Leia mais

ENSINET/NAV: UMA FERRAMENTA PARA ESTRUTURAÇÃO DE CURSOS BASEADOS EM OBJETOS DE APRENDIZAGEM *

ENSINET/NAV: UMA FERRAMENTA PARA ESTRUTURAÇÃO DE CURSOS BASEADOS EM OBJETOS DE APRENDIZAGEM * ENSINET/NAV: UMA FERRAMENTA PARA ESTRUTURAÇÃO DE CURSOS BASEADOS EM OBJETOS DE APRENDIZAGEM * Diego Lemos de Souza ** Graçaliz Pereira Dimuro *** Antônio Carlos da Rocha Costa **** Raquel Mello de Miranda

Leia mais

Guia para elaboração de artigos e construção de textos científicos

Guia para elaboração de artigos e construção de textos científicos Guia para elaboração de artigos e construção de textos científicos Lucio Mauro Braga Machado * Resumo: Este artigo de revisão orienta a construção de artigos científicos, desde a forma até a redação. Explana

Leia mais

Fasci-Tech MAPEAMENTO DOS PROCESSOS DE NEGÓCIO PARA DESENVOLVIMENTO DE UM SISTEMA INTEGRADO DE GESTÃO

Fasci-Tech MAPEAMENTO DOS PROCESSOS DE NEGÓCIO PARA DESENVOLVIMENTO DE UM SISTEMA INTEGRADO DE GESTÃO MAPEAMENTO DOS PROCESSOS DE NEGÓCIO PARA DESENVOLVIMENTO DE UM SISTEMA INTEGRADO DE GESTÃO Resumo: Carlos Alberto dos Santos 1 Profa. MSc. Rosangela Kronig 2 Abstract: Num ambiente globalizado e em constante

Leia mais

Levantamento de Requisitos.

Levantamento de Requisitos. FACULDADES INTEGRADAS MATO-GROSSENSES DE CIÊNCIAS SOCIAIS E HUMANAS RESUMO Levantamento de Requisitos. Leandro Cícero da Silva Mello. Prof. Jeanine Ferrazza Meyer Metodologia e Técnica de Pesquisa- Levantamento

Leia mais

FA PorT: Um Framework para Sistemas Portfólio-Tutor utilizando Agentes

FA PorT: Um Framework para Sistemas Portfólio-Tutor utilizando Agentes FA PorT: Um Framework para Sistemas Portfólio-Tutor utilizando Agentes Fábio Nicácio de Medeiros, Flávio Mota Medeiros, Arturo Hernández Domínguez Instituto de Computação Universidade Federal de Alagoas

Leia mais

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Lucas A. de Oliveira, Rui A. R. B. Figueira, Expedito C. Lopes Mestrado em Sistemas e Computação Universidade de Salvador (UNIFACS)

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

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

18º Congresso de Iniciação Científica UM ESTUDO EXPLORATÓRIO SOBRE TÉCNICAS DE MODELAGEM DE REQUISITOS DE SOFTWARE PARA SISTEMA EMBARCADO

18º Congresso de Iniciação Científica UM ESTUDO EXPLORATÓRIO SOBRE TÉCNICAS DE MODELAGEM DE REQUISITOS DE SOFTWARE PARA SISTEMA EMBARCADO 18º Congresso de Iniciação Científica UM ESTUDO EXPLORATÓRIO SOBRE TÉCNICAS DE MODELAGEM DE REQUISITOS DE SOFTWARE PARA SISTEMA EMBARCADO Autor(es) MARINA CALÇA Orientador(es) LUIZ EDUARDO GALVÃO MARTINS

Leia mais

O design de IHC. Jair C Leite. Jair C Leite

O design de IHC. Jair C Leite. Jair C Leite O design de IHC ERBASE EPOCA 2009 2010 Arquitetura e Engenharia Civil Idealiza, Concebe, Desenha Planeja e executa o projeto; realiza cálculos; gerencia recursos, custos e prazos. Design Industrial exemplos

Leia mais