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

2. 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.

3. 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)

4. Applications of S.E. Stand-alone applications
Client-server applications
Embedded Control Systems
Batch Processing Systems
Simulations
Data Collection Systems
Systems of Systems …

5. 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.

6. 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.

7. Cowboy Coders When given a job: Sometimes this is OK
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)

8. 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

9. Software_Engineering == not Cowboy_Coding

10. Typical Steps in S.E. Specification What are we trying to solve
game genre
major gameplay features
How will we get there
Major functions / classes (API)
(A)pplication (P)rogramming (I)nterface
Milestones
Division of Labor

11. Typical Steps in S.E., cont.
Software Design
Assign Tasks
Implement major features first
Testing
Very often while developing
Later, Alpha, Beta
Evaluation
Post-mortem
Sequel planning
There is almost always some back-and-forth between steps

12. Approaches to S.E (Waterfall)
Boss / producer comes up with high-level goals
The managers develop a high-level implementation plan
Art Lead
Programming Lead
Sound, Level, QA, etc Lead
The Leads assign jobs to the "grunts"
A "traditional" corporate structure
Very linear.

13. 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

14. 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.

15. 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.

16. Approaches to S.E. (Agile Programming)
Identify features / goals
Start with most important
Spend a short amount (a few weeks, often) implementing these features
Present the prototype to the consumer / boss
Based on feedback
adjust goals / features
adjust implementation plan
(sometimes) re-write earlier code
Go to step 2.
Repeat until consumer is happy / all goals met.

17. 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 perfer