DOCSLIB.ORG

Software Development Process Models

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Development Process Models Software Development Process Models From classical notions to more agile approaches Torsten Hahmann [email protected], BA8134 “Code & Fix” or “Cowboy Coding” 1) Write program 2) Test and fix program Problems: • program users not satisfied with program: definition phase (requirements & analysis) • fixing programs requires extensive program redesign: design phase • ill-prepared tests: test phase + implementation phase 29/09/06 Models of Software Development 2 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering What defines a development process? • Who does what at what time? • tasks • starting condition • documents (artefacts) received • output from previous stage • end conditions: finish criteria • final documents produced • input for next stage • order of tasks • who is involved • qualification • responsibility 29/09/06 Models of Software Development 3 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Development process models • Static process models • Waterfall model • V-Model • Incremental process model • Modern approaches • Iterative/Incremental process model • eXtreme Programming • Prototypic development • Test-driven development 29/09/06 Models of Software Development 4 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Waterfall model Software specification Design document 29/09/06 Models of Software Development 5 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Software specification I • 1. Goal • MUST • MAY • MUST NOT Software requirements • 2. Use of the product Analysis • Purpose • Target Group • Environment 29/09/06 Models of Software Development 6 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Example: Use Case diagram ehotel hotel reservation system inform <<actor>> book Pegasus Customer book book by book by online phone fax/email settle up ehotel clerk cancel cancel cancel by cancel by cancel online phone fax/email at Hotel Hotel (ehotel) (ehotel) (ehotel) clerk 29/09/06 Models of Software Development 7 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Software specification II • 3. Functionality • Can do a time estimate per „feature“ • Can track progress Software • 4. Data (persistent) requirements • 5. Performance Analysis • 6. User Interface • 7. Non-functional requirements & qualities Not too much details: -No implementation details (algorithms, data structure) -No technical solution (database, language, infrastructure) 29/09/06 Models of Software Development 8 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering V-model Use-case scenarios Acceptance Requirements test Validation Test cases System Analysis test Test cases Integration Design test Verification Coding Test Module (Modules) cases test 29/09/06 Models of Software Development 9 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Classical process models in a nutshell • problems of classical process models: • successive steps • document-driven • limited customers/users involvement • changing requirements in real world • pros: • customer gets a defined process (feasibility study) at the beginning of a project • can be good for large project-based developments • cons: • hard to think of all requirements at the beginning • documentation seems more important than program 29/09/06 Models of Software Development 10 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Scope • Project-based: contract between customer and contractor • clearly-defined overall goal • requirements: system functionality • non-functional requirements & qualities • e.g. large-scale software, e.g. logistics, industry, etc. • Commercial-of-the-shelf (COTS) product • constantly improving/changing releases • e.g. end-customer software (office, etc.) • Open-goal projects • e.g. academic research, prototypes, demos 29/09/06 Models of Software Development 11 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Incremental process model Initial definition complete software changes specification X=0 Design Define extended modefied model version X functionality X=X+1 changes partial architecture changes Code & test new ideas & wishes version X Product version X Use version X 29/09/06 Models of Software Development 12 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Agile development processes • Practices for every-day development required • focus on small and medium-sized software projects (small teams) • progressing, not spending too much time on design and specifications that might be useless • Agility • adaptable instead of predictable • “light-weight methodology” • minimizing risk by short-term focus (1-8 weeks) • being able to release a product after each cycle 29/09/06 Models of Software Development 13 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering „Agile Manifesto“ • Individuals and interactions over processes and tools • close, daily cooperation (possibly face-to-face) • self-organizing teams • trust in motivated individuals • Working software over comprehensive documentation • Working software is the principle measure of progress • Simplicity • Customer collaboration over contract negotiation • Responding to change over following a plan see http://www.agilemanifesto.org/ 29/09/06 Models of Software Development 14 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Development process models • Static process models • Waterfall model • V-Model • Incremental process models • Modern approaches (Agile) • eXtreme Programming • Prototypic development • Test-driven development 29/09/06 Models of Software Development 15 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering eXtreme Programming (XP) • Communication • questions instead of assumptions • „coach“ helps to overcome communication issues • Simplicity • try not to think of every eventuality in future • just implement what is really necessary • refactoring after iterations • Feedback • everybody gives and receives feedback • everybody is a little bit happier ☺ • Courage • try and compare alternative designs • no problem to throw away code 29/09/06 Models of Software Development 16 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Planning in XP • Plan by priorities (feature, defect tracking) • Plan for the next iteration • Take responsibility, do not delegate it • Use techniques like “story cards” 29/09/06 Models of Software Development 17 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Methods of XP • Pair programming • Best form of communication • Coding and Thinking • „Two pairs of eyes see more“ • Testing • No feature without test • Independent, automated tests • Extensive refactoring after each iteration • Strict coding conventions 29/09/06 Models of Software Development 18 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Software Prototypes • Software prototype different from „Product prototype“ • Help to elicit requirements • Paper prototypes (GUI) • Fake GUI • Basis for discussion • Experimental: can try & show alternatives • Practical experience & feasibility 29/09/06 Models of Software Development 19 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Categories of prototypes • Demonstration • for project acquisition • Explorative prototype • for analysis • Experimental prototype • evaluate design alternatives • show technical feasibility • Pilote system (evolutionary) • e.g. selected customer 29/09/06 Models of Software Development 20 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Horizontal vs. vertical prototype vertical prototype horizontal prototype 29/09/06 Models of Software Development 21 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Explorative Prototyping • Paper • Usability Engineering • try to find a good user interface design with prospective users • use: paper, post-it notes, colors • one developer: „plays“ software • one developer: takes notes • Software • fake GUI (Visual Basic, C#) • discuss it with customers • what do they expect will happen • what do they miss 29/09/06 Models of Software Development 22 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Test-driven development (TDD) • Principle 1: Test-First-Development (TFD) • For each feature: • write test first (including automation) • code afterwards • Principle 2: Refactoring • try to remove duplicate code • essential for keeping code simple • improve code quality • make it maintainable 29/09/06 Models of Software Development 23 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Test-driven development If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it? 29/09/06 Models of Software Development 24 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Test-driven development (TDD) • Advantages of TFD • immediate checking gives more confidence • can write several tests at the beginning of each release cycle • give a good overview of remaining effort • forces developers to write tests • But requires: Refactoring • otherwise software becomes unmaintainable TDD = TFD + Refactoring 29/09/06 Models of Software Development 25 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering When using agile methods? • Previously just „Code & Fix“ • A little bit more order, planning • Easier step than introduction of classical model • Small- & Medium-sized teams • About a dozen developers • Approaches • Volatile requirements • Motivated developers • Customers wish to be integrated 29/09/06 Models of Software Development 26 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Classical vs. agile processes • Classical processes (anticipating) • Disciplined, detailed plan • Emphasis on long-term planning Focus: process Plan-driven • Agile processes (adaptive) • Compromise between no and too much process • Short-term focus • Less documentation, code is documentation Focus: humans Agile 29/09/06 Models of Software Development 27 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering.
Load more

Recommended publications
  • Software Development Lifecycle (Sdlc) Models & Agile Methods
    sdlc% how did that happen? software development lifecycle (sdlc) models & agile methods • by analogy with civil engineering, where you design first, then do construction • in software, there is no “construction” it’s all design • used to be called coding sdlc%(2)% sdlc%(3)% • what is a software development process? • what is the lifecycle of a software project? • will talk about “agile” later. first, we’ll talk about “disciplined” or is it “traditional?” or is it “sturdy?” or is it “planned?” or is it… sdlc%(4)% example%feature%workflow% • tend to talk about sdlc in terms of a dichotomy – !“agile”!vs.!well…um…“not!agile”! – or,!“planned”!vs.!“con8nuous”! – others!tend!to!(incorrectly)!think!that!the! deployment!method!implies!the!process! • saas!==!agile! • installed!==!tradi8onal! • think more in terms applying the process on an individual feature, or an aggregate goal%of%sdlc% waterfall% Requirements! Design! Construc8on! • what’s the goal of a good sdlc? Integra8on! – passes!all!the!tests!(external!quality!aAriButes)! Debugging! – good!design/architecture!(internal)! Installa8on! Maintenance! – good!user!experience!(quality!in!use)! • move from one phase to the next only when its preceding phase is – process!quality!(can!process!help!ensure! completed and perfected. product!quality)! • first mentioned by Royce in 1970 as an example of a flawed, non- working model for software development. • US department of defence projects attempted to entrench this model by requiring their contractors to produce the waterfall deliverables and then to formally accept them to a certain schedule (US military standard DoD-2167) – there!was!a!unwieldy!process!for!going!Back!and!amending!previous! deliverables! waterfall%(2)% waterfall%(3)% more problems problems • static view of requirements – ignores volatility • lack of user involvement once specification is written • unrealistic separation of specification from design • often tracked with Gantt charts! • doesn’t easily accommodate prototyping, – printed!and!taped!up!on!the!wall! reuse, etc.
    [Show full text]
  • MAD SCIENCE! Ab Science Inc
    MAD SCIENCE! aB Science Inc. PROGRAM GUIDEBOOK “Leaders in Industry” WARNING! MAY CONTAIN: Vv Highly Evil Violations of Volatile Sentient :D Space-Time Materials Robots Laws FOOT table of contents 3 Letters from the Co-Chairs 4 Guests of Honor 10 Events 15 Video Programming 18 Panels & Workshops 28 Artists’ Alley 32 Dealers Room 34 Room Directory 35 Maps 41 Where to Eat 48 Tipping Guide 49 Getting Around 50 Rules 55 Volunteering 58 Staff 61 Sponsors 62 Fun & Games 64 Autographs APRIL 2-4, 2O1O 1 IN MEMORY OF TODD MACDONALD “We will miss and love you always, Todd. Thank you so much for being a friend, a staffer, and for the support you’ve always offered, selflessly and without hesitation.” —Andrea Finnin LETTERS FROM THE CO-CHAIRS Anime Boston has given me unique growth Hello everyone, welcome to Anime Boston! opportunities, and I have become closer to people I already knew outside of the convention. I hope you all had a good year, though I know most of us had a pretty bad year, what with the economy, increasing healthcare This strengthening of bonds brought me back each year, but 2010 costs and natural disasters (donate to Haiti!). At Anime Boston, is different. In the summer of 2009, Anime Boston lost a dear I hope we can provide you with at least a little enjoyment. friend and veteran staffer when Todd MacDonald passed away. We’ve been working long and hard to get composer Nobuo When Todd joined staff in 2002, it was only because I begged. Uematsu, most famous for scoring most of the music for the Few on staff imagined that our three-day convention was going Final Fantasy games as well as other Square Enix games such to be such an amazing success.
    [Show full text]
  • Exploring XP for Scientific Research
    focusExtreme Programming Exploring XP for Scientific Research William A. Wood and William L. Kleb, NASA Langley Research Center xtreme Programming, as an agile programming methodology, fo- cuses on delivering business value. In the realm of exploratory, long-term, small-scale research projects, prioritizing near-term E tasks relative to their business or scientific value can be difficult. Assigning even a qualitative monetary value can be particularly challenging for government research in enabling fields for which business markets have not yet developed. The conflict between near-term value and long-term research objectives leads to a culture clash when apply- the project using a GNU/Linux operating sys- ing basic XP practices. tem, the Emacs integrated development environ- We decided to explore this culture clash ment, and the Ruby programming language.1,2 when the Langley Creativity and Innovation Of- We had prior experience programming related fice solicited bids for exploring nontraditional algorithms for the advection-diffusion equation methodologies for aerospace engineering re- using Fortran but no experience in team soft- search. C&I was looking for a way to produce ware development, object-oriented design, extraordinary gains in productivity or enable unit testing, or programming with Ruby. entirely new applications. We submitted a bid As the project began, we realized that we and received one-year funding to perform a first had to deal with several cultural conflicts short prototyping assessment of XP at the before implementing the 12 XP practices. NASA Langley Research Center. We conducted Cultural conflicts Kent Beck lists nine environments that he says don’t work well with XP.3 Six of these Eight of Extreme Programming’s 12 practices are seemingly nine are counter to the existing culture at Lan- incompatible with the existing research culture.
    [Show full text]
  • Game Programming All in One, 2Nd Edition
    00 AllinOne FM 6/24/04 10:59 PM Page i This page intentionally left blank Game Programming All in One, 2nd Edition Jonathan S. Harbour © 2004 by Thomson Course Technology PTR. All rights reserved. No SVP,Thomson Course part of this book may be reproduced or transmitted in any form or by Technology PTR: any means, electronic or mechanical, including photocopying, record- Andy Shafran ing, or by any information storage or retrieval system without written permission from Thomson Course Technology PTR, except for the Publisher: inclusion of brief quotations in a review. Stacy L. Hiquet The Premier Press and Thomson Course Technology PTR logo and Senior Marketing Manager: related trade dress are trademarks of Thomson Course Technology PTR Sarah O’Donnell and may not be used without written permission. Marketing Manager: Microsoft, Windows, DirectDraw, DirectMusic, DirectPlay, Direct- Heather Hurley Sound, DirectX, and Xbox are either registered trademarks or trade- marks of Microsoft Corporation in the U.S. and/or other countries. Manager of Editorial Services: Apple, Mac, and Mac OS are trademarks or registered trademarks of Heather Talbot Apple Computer, Inc. in the U.S. and other countries. All other trade- Acquisitions Editor: marks are the property of their respective owners. Mitzi Koontz Important: Thomson Course Technology PTR cannot provide software support. Please contact the appropriate software manufacturer’s techni- Senior Editor: cal support line or Web site for assistance. Mark Garvey Thomson Course Technology PTR and the author have attempted Associate Marketing Managers: throughout this book to distinguish proprietary trademarks from descrip- Kristin Eisenzopf and Sarah Dubois tive terms by following the capitalization style used by the manufacturer.
    [Show full text]
  • Haruhi in Usa: a Case Study of a Japanese Anime in the United States
    HARUHI IN USA: A CASE STUDY OF A JAPANESE ANIME IN THE UNITED STATES A Thesis Presented to the Faculty of the Graduate School of Cornell University In Partial Fulfillment of the Requirements for the Degree of Master of Arts by Ryotaro Mihara August 2009 © 2009 Ryotaro Mihara ALL RIGHTS RESERVED ABSTRACT Although it has been more than a decade since Japanese anime became a popular topic of conversation when discussing Japan, both within the United States and in other countries as well, few studies have empirically investigated how, and by whom, anime has been treated and consumed outside of Japan. This research thus tries to provide one possible answer to the following set of questions: What is the empirical transnationality of anime? How and by whom is anime made transnational? How is anime transnationally localized/consumed? In order to answer the questions, I investigated the trans-pacific licensing, localizing, and consuming process of the anime The Melancholy of Haruhi Suzumiya (Haruhi) from Japan to the United States by conducting fieldwork in the United States’ agencies which localized Haruhi as well as U.S. anime and Haruhi fans. The central focus of this research is the ethnography of agencies surrounding Haruhi in the United States and Japan. I assume that these agencies form a community with a distinctive culture and principles of behaviors and practices in the handling of the Haruhi anime texts. The research findings to the above questions could be briefly summarized as follows. The worldview, characters, and settings of Haruhi (i.e. a fictious world of Haruhi which is embodied and described through its anime episodes and other related products) “reduces” and “diffuses” as it is transferred on the official business track from the producers in Japan to the localizers in the United States (i.e.
    [Show full text]
  • Risk Management and Agile Software Development: Optimizing Contractual Design
    Verlag Dr. Otto Schmidt 30.09.2016 CRi 6/2010 161 John P. Beardwood /Michael Shour Risk Management and Agile Software Development: Optimizing Contractual Design A recent report from Forester Research(Dr. Dobb’s I. Understanding (FR)AGILE Software Global Developer Technographics Survey Q3 2009) asked a cross-selection of 1298 IT professionals to iden- 1. Traditional Software Development tify which methodology most closely reflected the devel- Agile is perhaps best understood by contrasting it to opment process that such professional was currently Waterfall methods of development. The traditional using. At 35 %, the most popular response was Agile, in plan-driven software development model of the Water- comparison to a mere 13 % who responded that Water- fall process was initially conceived to manage the devel- fall was their current methodology of choice. Put opment of large software projects in the 1960s, such as another way, three times as many IT professionals used IBM’s System/360 operating system. Waterfall arranges Agile methodologies as did those who used Waterfall. software development into a sequential series of com- partmentalized phases, each with its own defined deli- Over the last ten years, Agile software development verables. A typical Waterfall process will be comprised methodologies – those which take an iterative and incre- of the following phases: requirements analysis; project mental approach, which aim to reduce unnecessary doc- planning and system design; coding; and integration and umentation and formality, and which seek to promote testing. 1 teamwork and experimentation – have increasingly been adopted by the software development community. The Waterfall process is characterized by planning, Agile’s advocates argue that by liberating programmers organization, and documentation.
    [Show full text]
  • The New XP Michele Marchesi
    The New XP Michele Marchesi “Even programmers can be whole people in the real world. XP is an opportunity to test yourself, to be yourself, to realize that maybe you’ve been fine all along and just hanging with the wrong crowd.” Kent Beck in Extreme Programming Explained — Second Edition In October, 1999, Kent Beck’s book “Extreme Programming Explained — Embrace Change” was published. Well, you may love or hate XP, but for sure you cannot say it was irrelevant. By publishing his book, sold in hundreds of thousand copies and translated in tens of languages, Beck started the tidal wave of agile methodologies. These methodologies can be fully adopted, partially adopted or not adopted at all, but no serious software engineer may overlook them. All new editions of software engineering textbooks now have a section on agile methodologies and XP. Five years after that book, Kent again took the stage and published — with Cynthia Andres — the second edition. And you can bet that it is not just a polishing or some addition. No, this second edition critically reviews what happened in these five years, and almost completely refunds XP, albeit sticking to the original principles, or just to be able to be faithful to them. In the first edition, XP was defined with four values, fifteen basic principles, and twelve practices. Also, Kent clearly wrote that to be XP, you had to fully apply all these famous twelve practices. Now, the twelve practices have disappeared! In the new XP, there are five values, fourteen principles, thirteen primary practices and eleven corollary practices.
    [Show full text]
  • Parallel Worlds: Agile and Waterfall Differences and Similarities
    Parallel Worlds: Agile and Waterfall Differences and Similarities M. Steven Palmquist Mary Ann Lapham Suzanne Miller Timothy Chick Ipek Ozkaya October 2013 TECHNICAL NOTE CMU/SEI-2013-TN-021 Software Solutions Division http://www.sei.cmu.edu Copyright 2013 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C- 0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. This report was prepared for the SEI Administrative Agent AFLCMC/PZE 20 Schilling Circle, Bldg 1305, 3rd floor Hanscom AFB, MA 01731-2125 NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution except as restricted below. Internal use:* Permission to reproduce this material and to prepare derivative works from this material for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works.
    [Show full text]
  • Introduction to Software Engineering
    Introduction to Software Engineering Edited by R.P. Lano (Version 0.1) Table of Contents Introduction to Software Engineering..................................................................................................1 Introduction........................................................................................................................................13 Preface...........................................................................................................................................13 Introduction....................................................................................................................................13 History...........................................................................................................................................14 References......................................................................................................................................15 Software Engineer..........................................................................................................................15 Overview........................................................................................................................................15 Education.......................................................................................................................................16 Profession.......................................................................................................................................17 Debates within
    [Show full text]
  • The Rapid Prototyping Process 29 What Is a Prototype: the 4 Dimensions 31 What to Prototype: 4 Ways to Combine Fidelity & Functionality 32 Takeaway 36
    Copyright © 2015 by UXPin Inc. All rights reserved. No part of this publication may be uploaded or posted online without the prior written permission of the publisher. For permission requests, write to the publisher, addressed “Attention: Permissions Request,” to [email protected]. Index 0. Introduction 6 1. A Practical Look at Prototypes 9 5 Reasons Why You Need to Prototype 10 How Prototypes Improve Collaboration & Communication 12 How Prototypes Add Balance to Design 14 How Prototyping Makes Usability Testing Easier 16 Why Prototyping Is Mandatory for Mobile 18 Takeaway 21 2. Choosing the Right Prototyping Process & Fidelity 22 When to Start Prototyping: 3 Points of Convergence 23 How to Prototype: The Rapid Prototyping Process 29 What Is a Prototype: The 4 Dimensions 31 What to Prototype: 4 Ways to Combine Fidelity & Functionality 32 Takeaway 36 3. Traditional Prototyping Methods and Tools 37 Paper Prototypes 38 Wizard of Oz Prototypes 44 Takeaway 47 4. Digital Prototyping Methods and Tools 48 Presentation Software 49 Coded (HTML) Prototype 52 Prototyping Software7 & Apps 55 Takeaway 58 5. Creating Prototypes for Usability Testing 60 Knowing Your Users: Personas, Scenarios, and Experience Maps 61 Usability Tests Before the Prototype 65 The Right Users and the Right Tasks 66 General Advice for Testing Prototype Usability 69 Different Fidelities for Testing Prototypes 71 4 Content Guidelines for Testing Any Prototype 73 Takeaway 75 6. 10 Prototyping Best Practices 76 1. Know Your Audience and Your Goals 76 2. Prime Your Audience Beforehand 77 3. Involve the Users (Participatory Design) 78 4. Focus on Flows and User Scenarios 79 5.
    [Show full text]
  • Download The
    Game Wrap ■ Editor in Chief Viktoriya Fuzaylova Editorial Board Game Wrap Volume 1 is Copyright (c) 2016 by New Viktoriya Fuzaylova England Interactive Literature. Copyrights to individual articles and larps herein remain with their respective Stephen Kohler authors. Brian Richburg Phoebe Roberts Th is work is licensed under the Creative Commons At- tribution-ShareAlike 4.0 International License. To view Adina Schreiber a copy of this license, visit http://creativecommons.org/ licenses/by-sa/4.0/. Author Liaison Brian Richburg Layout Designer Kathleen De Smet New England Interactive Literature c/o Chad Bergeron 258 Edgell Road Webmaster Framingham, MA 01701 Nat Budin ■ http://gamewrap.interactiveliterature.org EDITOR’S NOTE ESTEEMED READER! Welcome to the inaugural volume of Game Wrap, variety of games and role-play traditions that exist a magazine devoted to the art and craft of LARP. in our community and to welcome new infl uences. Please, allow me to introduce myself. I am the Th is brought up a fascinating and multifaceted magazine’s founder and fi rst Edi- debate about community identity and tor-In-Chief (self-appointed, how evolving language as exemplifi ed by else?), Viktoriya Fuzaylova. I would the diff erences in how the word LARP/ like to take up some space here to tell larp is spelled and used. (For more on you a little about this publication, how that, see one of our editors’ blogs.1) it came into being, and what we, the You may notice that within its pages staff , hope it can be. I want to highlight Game Wrap includes both.
    [Show full text]
  • Adapting Anime: Transnational Media Between Japan and the United States
    ADAPTING ANIME: TRANSNATIONAL MEDIA BETWEEN JAPAN AND THE UNITED STATES Brian Ruh Submitted to the faculty of the University Graduate School in partial fulfillment of the requirements for the degree Doctor of Philosophy in the Department of Communication and Culture, Indiana University May 2012 Acceptance page Accepted by the Graduate Faculty, Indiana University, in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Doctoral Committee ____________________________________ Barbara Klinger, Ph.D. ____________________________________ Gregory Waller, Ph.D. ____________________________________ Yeidy Rivero, Ph.D. ____________________________________ Scott O’Bryan, Ph.D. April 9, 2012 ii Acknowledgements I am very grateful to my Ph.D. committee – Barbara Klinger, Gregory Waller, Yeidy Rivero, and Scott O’Bryan – for supporting me (and putting up with me) for these last few years. My parents, Richard and Christine, and parents in law, Dan and Barbara Skinner, have been positive influences throughout this entire process, and I’m sure they’re all glad to see me finish. However, the person who may have borne the most stress through the entire process has been my loving wife Sarah. I’m so thankful to have her. I also need to acknowledge my two beautiful daughters Charlotte and Abby, the sources of both great joy and great delays in the writing process. And finally, hello to Jason Isaacs. iii Abstract Brian Ruh ADAPTING ANIME: TRANSNATIONAL MEDIA BETWEEN JAPAN AND THE UNITED STATES This dissertation examines Japanese animation, or anime, as an example of how a contemporary media product crosses national and cultural borders and becomes globalized. Bringing together the theories of Hiroki Azuma and Susan J.
    [Show full text]