DOCSLIB.ORG

Comparison of Software Development Methodologies Based on the SWEBOK

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Comparison of Software Development Methodologies Based on the SWEBOK Comparison of Software Development Methodologies based on the SWEBOK by El´ısio Maciel Sim~ao Supervisor PhD. Jo~aoMiguel Fernandes October 27, 2011 Contents List of Figures iii List of Tablesv Acronyms viii 1 Introduction1 1.1 Context . .1 1.2 Goals . .2 1.3 Structure of the Document . .2 1.4 Terms Elucidation . .3 2 State of Art5 2.1 Software Engineering . .5 2.2 Brief History of SDM . .6 2.3 Software Qualities . .7 2.3.1 Correctness . .8 2.3.2 Reliability . .9 2.3.3 Robustness . 10 2.3.4 Performance . 10 2.3.5 User Friendliness/Usability . 11 2.3.6 Verifiability . 12 2.3.7 Maintainability . 12 2.3.8 Re-usability . 13 2.3.9 Interoperability . 13 2.3.10 Productivity . 14 2.4 Knowledge Areas in Software Engineering . 14 2.4.1 Software Requirements . 15 2.4.2 Software Design . 18 2.4.3 Software Construction . 22 2.4.4 Software Testing . 23 i 2.4.5 Software Maintenance . 27 2.4.6 Software Configuration Management (SCM) . 30 2.4.7 Software Engineering Management . 32 2.4.8 Software Engineering Process . 34 2.4.9 Software Engineering Tools and Methods . 35 2.4.10 Software Quality . 36 3 SDM Descriptions 38 3.1 Software Development Methodologies . 38 3.2 Traditional Development Methodologies . 39 3.2.1 Waterfall Methodologies . 39 3.2.2 Transformation Methodologies . 44 3.3 Evolutionary Methodologies . 45 3.3.1 The Win-Win Approach . 45 3.3.2 Spiral Methodologies . 48 3.4 Rapid Application Development . 51 3.4.1 Changing Plans . 51 3.4.2 RAD . 51 3.5 Agile Development Methodologies . 56 3.5.1 Agile Manifesto . 56 3.5.2 Scrum . 58 3.5.3 eXtreme Programming . 64 4 Results 70 4.1 Method . 70 4.2 Waterfall . 71 4.3 Spiral . 75 4.4 Rapid Application Development . 79 4.5 Scrum . 83 4.6 eXtreme Programming . 87 5 Conclusions and further work 92 5.1 Conclusions . 92 5.2 Further Work . 94 Bibliography 99 ii List of Figures 3.1 The waterfall model . 40 3.2 Spiral Model, Boehm,1988 (CC) . 49 3.3 Rapid Application Development . 54 3.4 The Scrum Sprint [1]......................... 62 3.5 The Scrum Life Cycle [1]....................... 63 3.6 The Extreme Programming Life Cycle [1]............. 69 4.1 Waterfall: SoftwareKA satisfaction bar chart . 75 4.2 Spiral: SoftwareKA satisfaction bar chart . 79 4.3 RAD: SoftwareKA satisfaction bar chart . 83 4.4 Scrum: SoftwareKA satisfaction bar chart . 87 4.5 XP: SoftwareKA satisfaction bar chart . 91 iii List of Tables 3.1 Top-Down and Bottom-Up Strategies . 49 3.2 Risk in software projects . 49 3.3 Agile Manifesto . 56 3.4 The Twelve principles behind the Agile Manifesto . 57 3.5 Pig and Chicken roles: the joke . 59 4.1 Waterfall: Software Requirements, Software Design and Software ConstructionKA........................... 72 4.2 Waterfall: Software Testing, Software Maintenance and Software Configuration ManagementKA................... 73 4.3 Waterfall: Software Engineering Management, Software Engi- neering Process and Software QualityKA............. 74 4.4 Spiral: Software Requirements, Software Design and Software ConstructionKA........................... 76 4.5 Spiral: Software Testing, Software Maintenance and Software Configuration ManagementKA................... 77 4.6 Spiral: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 78 4.7 RAD: Software Requirements, Software Design and Software Con- structionKA............................. 80 4.8 RAD: Software Testing, Software Maintenance and Software Con- figuration ManagementKA..................... 81 4.9 RAD: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 82 4.10 Scrum: Software Requirements, Software Design and Software ConstructionKA........................... 84 4.11 Scrum: Software Testing, Software Maintenance and Software Configuration ManagementKA................... 85 4.12 Scrum: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 86 iv 4.13 XP: Software Requirements, Software Design and Software Con- structionKA............................. 88 4.14 XP: Software Testing, Software Maintenance and Software Con- figuration ManagementKA..................... 89 4.15 XP: Software Engineering Management, Software Engineering Process and Software QualityKA.................. 90 v Agradecimentos Gostaria de agradecer ao meu orientador o Prof. Doutor Jo~aoMiguel Fernandes pela paci^enciae cr´ıticaconstrutiva dada durante a execu¸c~aodeste documento realizado em simult^aneocom uma actividade profissional intensa o que aumen- tou ainda mais o desafio para mim e para ele. Gostaria tamb´emde agradecer `aminha fam´ılia(M~ae,Pai e Irm~ao)pelo apoio incondicional dado que reflecte o verdadeiro conceito de fam´ıliae que promove o que de melhor h´aem mim. Finalmente `aLiliana, por ser uma companheira de vida, e por estar sempre pre- sente nos bons e maus momentos tanto para criticar quer para motivar, quando ´epreciso. Obrigado! vi Abstract We are facing a period where software projects have a huge dimension involving small resources, high risk and a wide range of available approaches. In this scenario the Software Development Methodologies (SDMs) can prove to be a useful ally, but very dangerous and even fatal if misused. The big issue around this matter is how to choose the appropriated SDM that fits a specific project. In the given scope, this dissertation describes a framework for comparing SDMs delivering a set of procedures that should be followed when the choice of an SDM is made. The dissertation approaches the framework by applying it to a group of SDMs that were selected by their popularity and significance. This exercise is done to prove the concept of the framework and to provide a base comparison, with each chosen SDM, that can, and should, be extended by those who choose to use the framework. The classification is achieved by defining a scale that goes from total satisfaction to no satisfaction, with an intermediate level of partial satisfaction, that is ap- plied to a set of keys. These keys are based in SWEBOK (Software Engineering Body Of Knowledge) that describes and explains the different Knowledge Areas (KA) stating their common issues and best practices. To explain the frame- work, the dissertation analyzes eachKA and evaluates the selected SDMs by assessing how their approach complies with SWEBOK's knowledge areas, using the previous stated scale. The framework delivered can be enriched by its user who should provide weights to eachKA regarding the project in which the SDM will be used and previous experiences. vii Resumo Actualmente atravessamos um per´ıodo em que os projectos de software t^emuma grande dimens~ao,envolvendo baixos recursos, alto risco e com um variado leque de abordagens a escolher. Nestes casos as Metodologias de Desenvolvimento de Software (MDS) pode ser um bom aliado, contudo se mal escolhido pode ser extremamente perigoso ou at´efatal. A quest~aoque se levanta ent~ao´e,qual a metodologia a escolher. Neste contexto, este documento descreve um conjunto de procedimentos a seguir para comparar MDS. Os procedimentos s~aoent~aoaplicados a um conjunto de populares MDS provando o conceito aqui apresentado, disponibilizando uma compara¸c~aode base com uma explica¸c~aopara cada metodologia escolhida que pode, e deve, ser estendida por quem utilizar o conjunto de procedimentos aqui descritos. A classifica¸c~ao´econseguida atrav´esde uma escala que vai da satisfa¸c~aototal `a n~aosatisfa¸c~ao,com um n´ıvel interm´ediode satisfa¸c~aoparcial, para cada uma das chaves. As chaves escolhidas s~aobaseadas no SWEBOK (sigla de Soft- ware Engineering Body of Knowledge, em Portugu^es,Corpo de Conhecimento para a Engenharia de Software), que descreve e explica as diferentes ´areasde conhecimento da engenharia de software com refer^encia`asmelhores pr´aticas e problemas comuns para cada uma delas. Para o conjunto de procedimentos apresentado, cada uma das ´areasde conhecimento ´eanalisada e as MDS s~ao avaliadas de acordo com a forma como abordam cada uma das `areasde conhec- imento do SWEBOK utilizando a escala anteriormente referida. Estes procedimentos podem ser enriquecidos por quem o escolha utilizar atribuindo pesos a cada uma das ´areasde conhecimento com base no projecto a que a MDS ser´aaplicada e a experi^enciasanterirores. viii Acronyms ADM Agile Development Methodologies BDUF Big Design Up Front CASE Computer Aided Software Engineering CASL Common Framework for Algebraic Specification CMMI Capability Maturity Model Integration DSDM Dynamic systems development method FDD Feature Driven Development ITIL Information Technology Infrastructure Library KA Knowledge Area KLOC Kilo Line of Code PMBOK Project Management Body of Knowledge RAD Rapid Application Development RIPP Rapid Iterative Production Prototyping ROI Return of Investment SAGE Semi-Automated Ground Environment SCM Software Configuration Management SDLC Systems Development Life Cycle SDM Software Development Methodology SQM Software Quality Management SSADM Structured Systems Analysis and Design Methodology ix SWAT Skilled Workers With Advanced Tools SWEBOK Software Engineer Body of Knowledge TDM Traditional Development Methodologies UML Unified Modeling Language VDM Vienna Development Method XP eXtreme Programming x Chapter 1 Introduction 1.1 Context The importance of software in the world is constantly increasing, and with the increase of its importance also the size of the software systems is increasing as well as the effects of its development. These effects have consequences on the way software is developed. Software development of huge projects involves huge amounts of money and time, which have to be used in the correct way for delivering the final product with the minimal cost. With the evolution of software development, different approaches have been pre- sented and used to deliver a software product with aim of reducing time and cost of its development, without impairing the quality of the product. Each approach has its benefits and criticism but they all have similar goals, delivering a quality product in the fastest and cheapest way possible. When we look for a Software Development Methodologies (SDM) we have a set of very different perspectives, and even different approaches for the same perspectives, to choose from.
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]