Dr. Keith Shomper

1. CS 4810 Software Engineering I Dr. Keith Shomper

2. Objectives The Course Title is: CS 4810, Software Engineering I • Our objective – We are here to prepare students to serve God as software engineers by: • Gaining an understanding of how a major software development project is managed and conducted • In past courses we’ve concentrated on the requirements analysis and design in CS4810 and implementation, testing, and maintenance in CS4820. • Approach • Major project (2 semesters) • Some lecture • Some student presentations • A lot of “figure it out as you go”

3. Introduction • To a large extent, you will have a “clean slate” to work with on your development project • You will decide on the processes to use • You will decide on the document formats and how to apply tools such as UML and Rational Development Suite • You will determine the schedule for releases • Although I will have a schedule for progress reporting • Welcome to the “real world” • Think of yourself as a member of a small “startup” company • You don’t have any processes in place, and need to develop them from scratch

4. Introduction • So, we are here to study Software Engineering • Sounds good, but it would help to know what it is • Hopefully you have an idea of what Software is • Involves not only the code, but the associated documentation • But what is Engineering? • Accreditation Board for Engineering and Technology (the folks that accredit ENGR and will accredit us) definition: • The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practiceis applied with judgmentto develop ways to utilize, economically, the materials and forces of naturefor the benefit of mankind • Does this apply to what we do?

5. Introduction • Sommerville - “Software engineering is an engineering discipline which is concerned about all aspects of software production” • It is an engineering discipline • It applies established, time-tested methodologies • It is concerned about all aspects of software production • It involves the processes and tools for managing a software development project • It involves the product itself • Unfortunately, there is an inherent tension between managers and programmers • Managers live by the process • From programmers’ perspective, the process becomes the end in itself • Programmers focus on the product • “You don’t sell processes, you sell code” • Which perspective is correct?

6. Introduction • Hopefully we understand what Software Engineering is • But we haven’t addressed the why – why do we need software engineering? Computer software has become a driving force. It is the engine that drives business decision making. It serves as the basis for modern scientific investigation and engineering problem solving. It is a key factor that differentiates modern products and services. It is embedded in systems of all kinds: transportation, medical, telecommunications, military, industrial processes, entertainment, office products, … the list is almost endless. Software is virtually inescapable in a modern world. And as we move into the twenty-first century, it will become the driver for new advances in everything from elementary education to genetic engineering. Pressman … and we find it very difficult to develop

7. Introduction • Building software is hard … well, duh? The net result is that building and maintaining software is hard and getting harder; building quality software in a repeatable and predictable fashion is harder still - Grady Booch • Some estimates say that only about 30% of software development projects are successful • Even those that are successful leave us asking questions: • Why does it take so long to get software finished? • Why are development costs so high? • Why can’t we find all the errors before we give the software to the customer? (or why do we look so much like Microsoft) • Why do we have trouble gaining insight into how (or whether) the project is progressing?

8. Introduction • Bottomline: the days where software is developed by a guru who stays up all night eating pepperoni pizza are gone! • We need to learn to follow accepted “best practices” in a disciplined manner when we develop software • An engineer building a bridge doesn’t just “make it up as he goes” • There are established, accepted procedures • Developed over many years of experience • Unfortunately, software engineering is a very “young” discipline • We are still developing our “best practices” • Those that we teach today will probably be considered “feeble attempts” in just a few years

9. Introduction • The rapidly increasing complexity of software is one of the prime reasons we focus so much on software engineering • How many of you built a fort or a treehouse or a doghouse as a kid? • How does this differ from building a house, or SSC? • Hopefully we can see the need for more rigorous methodologies for developing software • That doesn’t necessarily make it fun • But we get much more utility out of a building like SSC than we would from a doghouse (unless of course you are a dog)

10. Introduction • Despite Claims of a Software Crisis—Why has it not materialized? • More “Stuff” to Build Upon • Better Communications • Better Development Tools • Easier Interfaces—More Standardized • Object-Oriented Paradigm • Better Languages and Libraries • Better Practices • This is SE. It improves our ability to make better s/w, but not dramatically so.

11. Introduction • With all this new emphasis on software engineering, the terminology is getting confusing - what am I? • Computer scientist? • Programmer? • Software engineer? • Computer scientists This is the segment of your education that remains fixed over a long period of time. Algorithms, Operating Systems, Boolean Math. These are academics. • Programmers stay up all night and eat pepperoni pizza • Industry isn’t all that interested in them anymore • Software engineers apply established practices to develop quality software

12. Introduction • Other terminology which might be confusing • Computer Engineer – mostly focuses on hardware • 70-30 hardware, versus 90-10 software • Often embedded systems which have combination of hardware/software • Systems Engineer – also combines hardware and software knowledge • Rather than doing detailed design of either, focuses on how to integrate the two • Involved in specifying the system, defining its overall architecture, and then integrating the different parts to create a finished system • Usually using COTS • If Cedarville were to go “wireless,” a systems engineer might specify what hardware and software to buy

13. Introduction • People are just now recognizing the need for Software Engineers rather than Programmers • In 1998, Texas became the first place in the U.S. where you can register as a professional Software Engineer • ACM and IEEE Computer Society are looking now at norms for establishing Software Engineering as a recognized engineering profession • We need to work to change the mindset from the idea of a Programmer to that of a Software Engineer • Some schools are offering degrees in Software Engineering rather than Computer Science Well, if we’re going to be engineers, guess it must be time for us to go buy our pocket protectors

14. Introduction • Software development is not well understood by most • Some software myths: • Software can be manufactured • “I need something that looks like this .. go build it” • Reality: it is more like building a bridge – every situation is unique and requires application of engineering judgment • If we get behind schedule, we can add programmers to catch up • Reality: adding people to a late software project makes it later • We provided our programmers with a great development environment: they have the best computer hardware • Reality: need to have (and use) software tools

15. Introduction • Software myths (cont) • Software doesn’t wear out • Hardware follows the “bathtub” curve • Software should just get better! Wearing out Infant mortality

16. Introduction • Software myths (cont) • Software doesn’t wear out (cont) • Reality: software doesn’t wear out like hardware, but it does deteriorate • As it gets “patched” over and over, the reliability of the software ends up decreasing, • Likewise, it gets more and more difficult to maintain • Objects and Components have revolutionized the reuse of software • Reality: most software still built from scratch • NIH (not invented here) syndrome

17. Introduction • Software myths (cont) • A general statement of objectives is sufficient to start writing programs; we can fill in details later • Reality: poor up-front definition of the problem is the major cause of failed software efforts • Project requirements continually change, but software is flexible and can easily accommodate change • Reality: Change early in the development process are relatively easy to incorporate. Change later in the process can have an order of magnitude more impact on cost and schedule • Once we get the code working, the job is done • Reality: Industry data shows that 60-80% of software development effort occurs after delivery to the customer • Bug fixes, enhancements

18. Introduction • Software myths (cont) • The only deliverable from a successful project is a working program • Reality: Documentation is essential • User will need documentation • Just as importantly, program cannot be maintained without proper documentation • Software engineering will require creation of voluminous and unnecessary documentation, and will slow us down • Reality: voluminous – yes; unnecessary – no • Doing it right the first time speeds the overall process • Having it documented for maintainability is indispensable to be able to make time-effective changes

19. Introduction • Summary: Software engineering was born out of the ashes of failed programs • It certainly goes against the grain of us “hackers” • But it has proven to be effective in producing successful projects • It is still in its infancy • Think about how many centuries we have been building houses/bridges and developing the “best practices” for this type of engineering • People have been thinking seriously about Software Engineering for only 10-15 years now • It is certain to continue to evolve and grow • Warning: don’t accept today’s fads as “gospel” and don’t think one magic technique will work for all projects • Process for large projects should be different than for small projects