TUG 2006

Using TSP in a Systems EngineeringEnvironment

“Lessons from the front”

Dan Wall

2TUG 2006

Problem

3TUG 2006

Agenda

n Systems Engineering / TSPn Game Development

Challengesn Anatomy of a Gamen Lessons Learnedn Summary

4TUG 2006

Gaming Challenges

n Consumer expectationsn Bigger, better, innovation (graphics, game play)

n Competitive environmentn Large multi-discipline, multi-team projectsn Development is riskier than evern Fixed datesn Limited resources

n Game development culturen Immature practicesn “In the garage” development mentality

n Evolving Hardware

5TUG 2006

Anatomy of a GameFour distinct disciplines

AnimationArtDesignEngineering

LifecycleProposalPre-productionProduction

1st playableAlphaBetaLot check

Pre-ProductionEntry Criteria

Approved ProposalBudget and FTEs available

Establish plan for game developmentSolidify vision for the gameResearch major risk areasAlign resources to fit project needs

Determine Project Slotting Active Queue

No

Store for later use

Create Project Charter

Determine Resource

Projection Plan

Setup Project

Determine Customer

Communication Plan

Launch Project

Create GDD

Create TDD

Create ADD

Determine Localization

needs

Select/Build Tools& Build System

Develop Preliminary

Scenario Outline

Determine Contractor Evaluation

Prototype Game on H/W

Develop Major Systems

Historical Data

Project Prep

Create Audio Spec

OK

No

Yes

Project Data

Art asset listStyle Guide

Project VisionMajor GameplayRough feature SetRough Scope

Capabilities of target platformArchitectureRough BudgetsAlchemy

Asset verificationToolsBuild

Outline of sound effects,Music and VO

Project Tracking Size, Effort, Defects, Cost, Schedule, Budget, Performance

To Production – 1st

Playable

From Proposal

Preliminary version of:CameraPlayer HandlingAIScripting SystemPhysicsSFXUI

Sample mission / levelWorld layoutConcept Art

Objective

As necessary

6TUG 2006

Systems Engineering / TSP

Systems Engineering“The interdisciplinary approach governing the total technical and managerial effort required to transform a setof customer needs, expectations, and constraints into a product Adaptation and support that Adaptationthroughout the products’ lifecycle. This includes the definition of technical performance measures, theintegration of engineering specialties towards the establishment of a product architecture, and the definition ofsupporting lifecycle processes that balance cost, performance, and schedule.”

CMMI glossary

TSP The Team Software Process (TSP) is an integrated set of practices for developing software.

TSP is an effective adaptation to common software engineering and management issues.n cost, schedule, productivity, and quality managementn software project managementn security and safetyn acquisition and contract management

7TUG 2006

SE / TSP Challenges

n Setupn Trainingn Measurement Frameworkn Support Tools

n Practicen Implementingn Making it work

8TUG 2006

Training

PSP and TSP trainingmaterial was notcreated with otherdisciplines in mind

Concepts andprinciples still apply

n Exercises not designed forthese disciplines

n Terminology mismatchesn Required

9TUG 2006

Measurement FrameworkNeed to create a new framework that supports all

disciplines

n Existing TSP Measurement Framework will not work forother disciplines

n Non trivial exercisen Involve usersn Takes more time than you thinkn Not easy to understand for non process typesn Will require several iterations

n Difference between process and frameworkn Has data analysis implications

10TUG 2006

Support Tools

Tool is crucial to a successful implementation

Tooln instantiates the TSP process, concepts and principlesn captures datan provides project status

Need a tool that supportsn multiple disciplines,n multiple user types,n varied processes,n measures, andn data analysis

Useable, scalable, and customizable

11TUG 2006

Implementation

n Standard TSP introduction strategy is notenough.

n Needs modification, expansion for non softwaredisciplines

n Practice basic software process improvementn Levels of maturity by discipline

n Basic project mgmt, std processes, quantitative …

n Need to involve the whole organizationn Stepwise improvementn Communication, communication, communication

12TUG 2006

Implementation

n Diffuse Concepts to other projectsn Project Kick-offs and/or “reality checks” use

n Mtg1n Mtg3 to review conceptual designn Planning with realityn Cross-functional check for dependenciesn Risks – what worries you about this project

n Project Reviews and Post-mortems

n Wag the dogn Use Test group to help drive quality goals

n Leverage data, focus on high cost problems

13TUG 2006

Making it work1

Challengesn Multiple discipline in one projectn Unique aspects of each additional disciplinen Discovery aspect of Game Developmentn Using only a small portion of the TSP

e.g. Quality Plan, Role Managers

14TUG 2006

Making it work2

Multiple disciplines

Adaptationn Multi-team launch preparationn Normal Multi-team launch sequence, with the

following changesn Mtg. 2 – break into groups by discipline to define sub-

group goals, group review; additional/different RoleManagers

n Mtg. 3 – break into groups by discipline to defineprocesses, work products, group review.

n Mtg. 4 – sub-groups estimate work, full group review ofcross discipline tasks and dependencies

n Mtg. 5 – focus on several key defect typesn Mtg. 6 – workload balance within discipline

15TUG 2006

Making it work3

Multiple disciplines

Adaptationn Additional and different Role Managers

n Multiple views of project informationn Ability to have multiple WBS hierarchiesn Rollups by discipline, by milestone, by project

n Occasional discipline team meetingsn Leadsn Teams

16TUG 2006

Making it work

Unique aspects of each disciplineDifficulty with consistent data collection throughout the lifecycleDefining sizeDefining defects

Adaptationn Set clearer expectations

n Discipline specific trainingn Team member coaching, weekly workbook reviewn Exec Producers review team data and collection

compliance

n Capture data and analyze itn Require Personal post-mortems

n Defectsn Work with each to fine a common definition

17TUG 2006

Making it work

Discovery aspect of game developmentContinual prototyping

Adaptationn Shortened planning cycles

n 4-6 weeks instead of 8-12 weeksn Personal and team post-mortems before next cycle relaunch or

plann Refined game development process definitions

n Multiple passes

18TUG 2006

Making it work

Using only a small portion of the TSPAll disciplines are not ready for the full TSP

e.g. size measures, lack of historical data, planning guidelines

Adaptationn Use a phased introduction of PSP concepts

n TSP0, TSP0.1, TSP1, TSP1.1, TSP2, TSPn Introduce new concepts when personal and

project post-mortems indicate the team is ready

19TUG 2006

Contact Information

Dan WallVP Production Methods150 Broadway Suite 205Albany, NY 12204

DWall@vvisions.com

(518) 701-2512

20TUG 2006

Game Factoids

Average age of a “gamer” 29

More $$ spent on games than movies

$11.5B spend US in 2005

1952 1st game

1961 Spacewar

1970s PONG, Asteroids, Zork, Adventure, …

1980s Space Invaders, Donkey Kong, Tetris, …

1990s Doom, Myst, …

2000s Call of Duty, GTA, …

21TUG 2006

Software

Activitiesn Low level H/W manipulation

n Error handlingn RAM, ROM, CPU, GPUn Memory allocationn Timingn Read / write storage

n UIn Input controlsn File Management system

n Progressionn Data (de) compression

n Physicsn Localizationn Cameran Lightingn Renderingn Collision

Software Processn Varies

n Handlingn Replay capabilitiesn Game modesn Special FXn Optimization

n Networkingn Peer to Peern WiFin External online services

n Toolsn Scripting languagen Art and Animation

n Conversionn Import / Exportersn Level Development