1. Software Engineering References: "Software Engineering, 9 th 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 ) 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: – 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. 1.Specification a.What are we trying to solve i.game genre ii.major gameplay features b.How will we get there i.Major functions / classes (API) (A)pplication (P)rogramming (I)nterface ii.Milestones iii.Division of Labor

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

12. Approaches to S.E (Waterfall) 1.Boss / producer comes up with high-level goals 2.The managers develop a high-level implementation plan a.Art Lead b.Programming Lead c.Sound, Level, QA, etc Lead 3.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) 1.Identify features / goals a.Start with most important 2.Spend a short amount (a few weeks, often) implementing these features 3.Present the prototype to the consumer / boss a.Based on feedback i.adjust goals / features ii.adjust implementation plan iii.(sometimes) re-write earlier code b.Go to step 2. c.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 prefer