1 / 17

Software Engineering

Software Engineering. References: "Software Engineering, 9 th ed." ( Addison-Wesley 2011 ). What is it?.

ronat
Download Presentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering 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: • 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 == notCowboy_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 someback-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 prefer

More Related