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

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

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

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.

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

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