Software Engineering

References:• "Software Engineering, 9th ed." (Addison-Wesley 2011)

What is it?

• "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software"

SWEBOK (Software Engineering Body of Knowledge)• Not necessarily the same as writing a

program.

An analogy• Architects (Software Engineers)– Design the building– Plan the layout, look, #rooms, type of structure,

etc.– Conform to building codes– The "planner", not the "builder"

• Construction Worker (Coders)– Follows the blueprint designed by the architect.– The "builder", not the "planner"

• Do you need an architect?– Small (toolshed) vs. Large buildings (hospital)

Applications of S.E.

• Stand-alone applications• Client-server applications• Embedded Control Systems• Batch Processing Systems• Simulations• Data Collection Systems• Systems of Systems• …

Costs of S.E.

• You must invest time• Delays start of development• Often more paperwork / beauracracy• Requires lots of communication– With team members– With clients / bosses / etc.

Benefits of S.E.

• Avoids wasted efforts• Helps produce cleaner code– More readable– More extensible– More error-proof– More elegant

• Improves customer satisfaction• (for you) a very marketable career– Money Magazine (2006) #1 job prospect in U.S.A.

Cowboy Coders• When given a job:– No planning whatsoever– Start working immediately.– Get it to work as quick as possible.– Turn in the lab and forget it

• Sometimes this is OK– For small projects you won't use again.– When working by yourself– Quick tests, proof of concept (example code in class)– Non-critical systems (some critical systems are:

warhead targeting, medical records, etc)

Hallmarks of Cowboy Coders• Spaghetti code• No planning on how everything will fit together• Little / no commenting• Poor naming conventions• Ignore bugs – "It's working most of the time"• Not easily read by others• Not easy to expand upon• Poor (or no) use of modularity features

– modules– functions– classes

• Little (or no) intermediate (or unit) testing• No planning for future use of the software

Software_Engineering == not Cowboy_Coding

Typical Steps in S.E.

1. Specificationa. What are we trying to solve

i. game genreii. major gameplay features

b. How will we get therei. Major functions / classes (API)

(A)pplication (P)rogramming (I)nterface

ii. Milestonesiii. Division of Labor

Typical Steps in S.E., cont.2. Software Design

a. Assign Tasksb. Implement major features first

3. Testinga. Very often while developingb. Later, Alpha, Beta

4. Evaluationa. Post-mortemb. Sequel planning

• There is almost always some back-and-forth between steps

Approaches to S.E (Waterfall)

1. Boss / producer comes up with high-level goals2. The managers develop a high-level

implementation plana. Art Leadb. Programming Leadc. Sound, Level, QA, etc Lead

3. The Leads assign jobs to the "grunts"• A "traditional" corporate structure• Very linear.

Waterfall analysis

- A lot of bureaucracy- Typically slower to start- Hard to change goals / respond to changing customer needs.- Hard to plan for large / new / complex systems+ Easier to ensure quality, reliability, lack of errors+ Less chance of feature creep

Approaches to S.E. (Re-use oriented)

• Type#1:– Use an "off-the-shelf" middleware product• Unreal, Havok, Bink, Unity, etc.

– Typically there is "glue" code needed.• Type#2:– Develop your software as an "Engine"– Try to make it as general as possible.

Re-Use oriented analysis

Type #1:- Limited by engine's features- Usually very expensive

Type #2:- Generality (usually) == more time / effort- Re-inventing the wheel+ Design only those features (that might be

or are currently) needed- Planning a large project is hard.

Approaches to S.E. (Agile Programming)

1. Identify features / goalsa. Start with most important

2. Spend a short amount (a few weeks, often) implementing these features

3. Present the prototype to the consumer / bossa. Based on feedback

i. adjust goals / featuresii. adjust implementation planiii. (sometimes) re-write earlier code

b. Go to step 2.c. Repeat until consumer is happy / all goals met.

Agile Proramming Analysis

- More chance of re-doing components- Harder to predict milestones- Susceptible to feature creep+ Less paperwork / (initial) planning+ More flexible from consumers point of view+ (Sometimes) quicker turn-around time

• Anecdotally, this seems to be what many (indie) game companies prefer