Software Development Process - Northeastern Universityrequirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration Acceptance test Service

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!)


ò 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



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!)

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?




ò  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”


ò 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










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










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










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










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



Use Case










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



Use Case










Use Case










Activity Diagrams

ò  Used to describe more complex dynamic behavior, adding to sequence diagram.

ò  This is especially important for threading or multi-process algorithms