 Randy Ribler – Lynchburg College  PhD from Virginia Tech  Postdoc at University of Illinois (UIUC)  Many years of industry experience building systems   I was here before in 2006  I’m absolutely delighted to be back in 2013

 Hobbs Hall

 How do we build big systems?  How do people work together best?  How can we prevent project failure?  Failure rates are debatable, but undeniably too high  How should individual programmers do their jobs?  What are “best practices”

 Fewer things are provable  Hard/Impossible to repeat anything  Every situation is a different  Projects are different  Staff is different  Tools are different  Customers are different  SE has been wrong before  Conventional wisdom has changed radically in the last several years.

 Structured Programming  Object-oriented Programming  Design Patterns  Configuration Management  Pair Programming  Test-driven Development  Refactoring  A number of software process models  Coding Standards  Tools

 Chaos!  No agreement on exactly what the system must do  No comprehensive high-level design  Difficult coordination between team members ▪ How do we know what we should be working on ?  What happens if someone leaves?  How do we bring all the pieces together?

 Requirements  Determine exactly what the system must do. Generally, say nothing about how it does it.  A requirements specification document is produced.  System Design  High-level design breaks the system in to pieces (modules) ▪ Describe how each of the pieces work and communicate.  Low-level design ▪ Write pseudo-code for all the modules  Design documents are produced

 Implementation (Coding)  Typically cited as expected to take 10-15% of project time.  Testing  Unit testing  Integration Testing  Deployment  Deliver the system to the customer ▪ Sometimes this is the first time the customer has seen the system work!

 Maintenance  Debug problems  Make Enhancements  This phase is acknowledged to be the most expensive

 Follows other engineering disciplines – “Have a blueprint before you build anything”  The entire system is planned from the beginning, allowing design to be comprehensive.  The customer is told what they will get from the beginning  Good for contracts, at least on the surface  Module breakdown provides parallelism of effort.

 The less sure we are about what we want the more expensive it will be  What happens if the project is cancelled before deployment?  How do we keep all the documents consistent?  How do we know that the system will solve the user’s problem?  How do we know how long things will take?  It is unclear how effective it is.