View
4
Download
0
Category
Preview:
Citation preview
Software Engineering Text (chapters 1 and 3)
Software Development Process
What is Software Process?
ò Ac#vi#es: ò Specifica#on (what) ò Design (how) ò Coding/development ò Tes#ng/valida#on ò Maintenance (change!)
What is Software Process?
ò Ac#vi#es: ò Specifica#on (what) ò Design (how) ò Coding/development ò Tes#ng/valida#on ò Maintenance (change!)
Specification (What) ò Feasibility study
Can we do it using the tools, 1me and budget constraints?
ò Requirements Analysis Figuring out specifics of what we need to do
ò Requirements Spec. Document everything you found out.
ò Requirements Valida8on Show them to customers, do prototypes
Specification – Documents
ò UI Spec ò Use Case Scenarios ò Prototype ò Test Results of prototypes
What is Software Process?
ò Ac#vi#es: ò Specifica#on (what) ò Design (how) ò Coding/development ò Tes#ng/valida#on ò Maintenance (change!)
Design (how) ò Architecture
Subsystems, and their rela1onships ò Abstract spec.
Subsystem services and constraints ò Interface Design
Methods or messages between subsystems
ò Component Design
ò Data Structure and Class Design (if OOD) ò Algorithm Design
Design: Structured Models
ò Data-‐flow model
ò En8ty Rela8on model (should have seen that in Dbase)
ò Object oriented methods (inheritance, class/object interac#on and rela#onship)
ò State Transi8on models
What is Software Process?
ò Ac#vi#es: ò Specifica#on (what) ò Design (how) ò Coding/development ò Tes#ng/valida#on ò Maintenance (change!)
What is Software Process? ò Ac#vi#es:
ò Specifica#on (what) ò Design (how) ò Coding/development
ò Tes#ng/valida#on ò Maintenance (change!)
Testing
ò Unit Tes#ng ò Module/object tes#ng
ò Subsystem tes#ng
ò System tes#ng
} Done by programmer
} Done by testing group
Testing: Verification and Validation ò Verifica8on: are we building the product
right? (test against specs) ò Valida8on: are we building the right product?
(test with the user)
How do you translate that for your game?
What is Software Process?
ò Ac#vi#es: ò Specifica#on (what) ò Design (how) ò Coding/development ò Tes#ng/valida#on ò Maintenance (change!)
What is Software Process?
ò Ac#vi#es: ò Specifica#on (what) ò Design (how) ò Coding/development ò Tes#ng/valida#on ò Maintenance (change!)
How do you translate this process to games?
Software Myths
“ If we are behind the schedule, just add more programmers”
“Nine Women cannot make a baby in nine months”
Software Myths
“ Once we write the program and get it to work, our job is done”
“60%-‐80% of all effort expended on so5ware will be expended a5er it is delivered for the first <me”
What is Software Process?
ò Activities:
ò Specification (what)
ò Design (how)
ò Coding/development
ò Testing/validation
ò Maintenance (change!)
In what order?
Challenges
ò Wiked problems
ò Customers don’t know what they want
ò Hard to change code, esp. with evolu#on of programming languages
Methods the people developed
ò The waterfall model
ò Separate and dis#nct phases of specifica#on and development
ò Evolu8onary development
ò Specifica#on and development are interleaved
ò Formal systems development
ò A mathema#cal system model is formally transformed to an implementa#on
ò Reuse-‐based development
ò The system is assembled from exis#ng components
Waterfall Model (1970) Requirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
Advantages and Disadvantages
ò Good when requirements are understood and problem has been aPached before
ò Cannot adapt to rapidly changing requirements or ill-‐defined problems
Building a software is like driving
“ Driving is not about geJng the car going in the right direc1on. Driving is about constantly paying aKen1on, making liKle correc1on this way, a liKle correc1on that way” – from XP
Evolutionary Development
ò Exploratory development
ò Objec#ve is to work with customers and to evolve a final system from an ini#al outline specifica#on
ò Throw-‐away prototyping ò Objec#ve is to understand the system
requirements. Should start with poorly understood requirements
Evolutionary Development
ò Problems
ò Lack of process visibility ò Systems are oTen poorly structured
ò Special skills (e.g. in languages for rapid prototyping) may be required
ò Applicability ò For small or medium-‐size interac#ve systems
ò For parts of large systems (e.g. the user interface)
ò For short-‐life#me systems
Reuse Oriented Development
ò Requirements Spec.
ò Research Exis#ng Components
ò Rework Requirements
ò Design
ò Component Integra#on and tes#ng
Process Iteration
ò System requirements ALWAYS evolve in the course of a project so process itera#on where earlier stages are reworked is always part of the process for large systems
ò Two (related) approaches ò Incremental development ò Spiral development
Incremental Method
Spiral Model ò Process is represented as a spiral rather than as a
sequence of ac#vi#es with backtracking
ò Each loop in the spiral represents a phase in the process.
ò No fixed phases such as specifica#on or design -‐ loops in the spiral are chosen depending on what is required
ò Risks are explicitly assessed and resolved throughout the process
Spiral Method
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
designCode
Unit testIntegration
testAcceptancetestService Develop, verify
next-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phaseIntegration
and test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
Project
ò Pitch (Presented Oct 29)
ò High Level Design document (Nov 7)
ò Prototype 1 (Nov 14)
ò Prototype 2 (Nov 26)
ò Prototype 3 (Dec 3)
ò Final Game Show Case (Dec 5), video and presentation video
UML All materials (including images) are taken from: http://edn.embarcadero.com/article/31863 and
http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/diagrams.htm
UML (what is it?)
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
Why do you think you need this?
Use Case
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
Use Case Diagrams
Use cases in Game Development
ò In games use cases are important for:
ò Testers to ensure all user interactions are satisfied
ò Developers to determine the features for the interaction
Use Case
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
Class Diagrams
Class Diagrams in Game Development
ò In games developers use class diagrams to:
ò Document the systems involved
ò Share and discuss among other developers
ò Code review and assessment to increase maintainability of the code especially for engine code or franchise games
Use Case
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
Object Diagrams
ò Just like the class diagram but with objects instead. This is useful to show the relationships between objects not just classes
Use Case
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
Sequence Diagram
ò Shows the dynamics of the systems. Specifically the sequence of operations between objects.
Green bar: when object has control Red box: object destroyed Blue bar: object active
Sequence Diagrams in Game Development
ò In games developers use sequence diagrams to:
ò Document the dynamics of the systems
ò Share and discuss among other developers
ò Code review and assessment to increase maintainability of the code especially for engine code or franchise games
Use Case
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
State Diagrams
ò State diagrams describe the behavior of the system. They describe the state of the object when an event occurs
State Diagrams in Game Development
ò In games developers use state diagrams to:
ò Document the behavior of objects, specifically AI behaviors
ò Share and discuss among other developers
ò Code review and assessment to increase maintainability of the code especially for engine code or franchise games
Use Case
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
Use Case
ò Unified Model Language
ò Standardized representations or models for explaining software design and architecture (like the blueprints of the software)
ò Use case diagrams
ò Class diagrams
ò Object diagrams
ò Sequence diagrams
ò State chart diagrams
ò Component diagrams
ò Activity diagrams
Activity Diagrams
ò Used to describe more complex dynamic behavior, adding to sequence diagram.
ò This is especially important for threading or multi-process algorithms
Recommended